[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED



Hello

So what happened if anyone will upgrade from Jessie (stable) to Stretch
(when it'll become stable in near future)

As I see that is an update from 1.7.11 to 1.10.7.

If this isn't possible it should be an RC. In general it is not
necessary to do an update to stable-backports in the meantime.

So the update path from 1.7.11 to 1.10.7 should be complete.

Just my 2 ct.

Kind regards

Mechtilde

Am 25.05.2017 um 10:11 schrieb Neil Williams:
> On Thu, 25 May 2017 18:00:34 +1000
> Brian May <bam@debian.org> wrote:
> 
>> Thorsten Glaser <t.glaser@tarent.de> writes:
>>
>>> How, by the way, is the upgrade from jessie to stretch handled?
>>> If this makes users lose data (without using the 1.8 packages)
>>> that’s probably an RC bug.  
>>
>> Django is just a Python library. Django itself has no data or
>> configuration. Upgrading/Downgrading it will not affect data in
>> anyway.
> 
> No, sorry. Changes in the code have a direct effect on the user data,
> it is unavoidable.
> 
> Django is an Object Relational Model. It directly controls user data in
> the database. Upgrading django changes the way that the model is mapped
> to the data with new models, new fields and deprecation of old models
> and fields.
> 
> When the django code changes, there must be database migrations created
> which run ALTER TABLE SQL calls during the installation of the package
> using django.
> 
> If a feature is deprecated in one LTS and removed in the next, then the
> developer release after that will simply fail to handle the migration
> which runs the ALTER TABLE. This is what happens with 1.7 to 1.10. The
> migration process fails because 1.8 changed the way that dependencies
> are handled within the migration process.
> 
>> It is the applications that use Django that may have to handle data
>> migrations. An version of an application that supports a newer version
>> of Django will typically be a newer version that could have database
>> changes.
> 
> Except when django itself changes the way it calculates how to process
> those migrations, as happened with 1.8.
> 
>> This is typically handled with Django DB migrations. There should not
>> be any problems migrating from one upstream version to new version
>> (if they have done their job correctly), the migrations keep track of
>> what needs to happen automatically.
> 
>> Having an intermediate step between Jessie and Stretch does not change
>> this in anyway. You will still end up running exactly the same
>> migrations by the time you install the Stretch version.
>>
>> There might be configuration files that also need to be updated,
>> depending on the application. Not getting this right shouldn't cause
>> any data loss however.
> 
> I'd welcome any input into the bug report itself but everything you
> describe is how it is expected to work. It is not how it is actually
> working and I believe this is down to how django changed the way that
> is calculates the dependencies of the migrations.
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: