Re: 1.8 release planning

[Aymeric Augustin]

Hello,

This timeline was discussed by the core team today at Django under the Hood and 
approved.

The support period for Django 1.4 will extend for six months after the release 
of Django 1.8.

The recommended way to migrate from 1.4 to 1.8 is to go through 1.5, 1.6, and 
1.7. I encourage you to start this process early if you expect it to take time.

-- 
Aymeric.



> On 17 oct. 2014, at 21:48, Tim Graham  wrote:
> 
> I'd like to kickoff the discussion on the timetable and process for the 1.8 
> release. I am also volunteering to be the release manager.
> 
> First, a retrospective on the 1.7 release with planned release dates and 
> (actual):
> 
> Jan. 20: alpha (Jan. 22)
> March 6: beta (March 20)
> May 1: RC (June 26)
> May 15: final (Sept. 2)
> 
> One observation I have is that each stage of the release does not really do a 
> good job at accurately reflecting our belief about the quality of the code. 
> For example, we have an "alpha" in order to have a major feature freeze, but 
> we still allow a significant amount of minor features (3 months worth in the 
> last release) such that the alpha and beta are hardly comparable. Likewise, 
> we had little confidence that the "RC" would actually be released without 
> further changes, but rather we needed to do the release in order to get to 
> the stage where we would only backport release blocking bugs. Therefore, I am 
> going to propose returning to a process that is closer to what's documented 
> in the Release cycle docs [1]. The idea is to front-load all feature work to 
> pre-alpha so that we can become more conservative with backports sooner.
> 
> Here is my proposed schedule:
> 
> Jan. 12: alpha
>   - Feature freeze including minor features (minor features were allowed 
> until beta in the past)
>   - fork stable/1.8.x from master (in the past we forked after beta, but now 
> that we'd no longer accept minor features after alpha, we'd need to fork 
> sooner).
>   - I picked this date since it is after the end of the year when I imagine 
> many people are on holiday and therefore able to contribute more to open 
> source.
>   - Non-release blocking bug fixes may be backported at the committer's 
> discretion after this date.
> 
> Feb. 16: beta
>   - Only release blocking bugs are allowed to be backported after this date.
>   - Aggressively advertise it for testing
> 
> March 16: release candidate
>   - Hopefully a true release candidate. If there is still a consistent stream 
> of release blockers coming in at this date; we'd release beta 2 to encourage 
> further testing and push the release candidate date out ~1 month.
> 
> March 30: final
>   - Release a final as long as the release blocker stream is sufficiently 
> low. If not, give an update about the status and make a plan as to how to 
> proceed from there.
> 
> On a related note, I believe we should give some guidance on our thinking 
> regard LTS. Currently our docs say, "Django 1.4, supported until at least 
> March 2015." If we adopt 1.8 as the next LTS, I propose to support 1.4 until 
> 6 months after 1.8 is released, which would be at least September 2015. Like 
> 1.4, we'd advertise LTS support for 1.8 for at least 3 years after it's 
> released with a decision on the next LTS to be made as we approach that date.
> 
> Feedback on the proposed schedule and handling of the LTS cycle would be 
> appreciated!
> 
> If you have any major features you plan to shepherd for this cycle, please 
> ensure they are listed on the roadmap: 
> https://code.djangoproject.com/wiki/Version1.8Roadmap 
> 
> 
> [1] 
> https://docs.djangoproject.com/en/dev/internals/release-process/#release-cycle
>  
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1ace477f-1ead-4554-bb8c-bb86d6347679%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group 

Re: 1.8 release planning

[Tim Graham]

Spot on, that's why I proposed a total feature freeze at alpha instead of 
beta and becoming more conservative with backports earlier in the release 
cycle. I hope that advertising 1.8 as the next LTS will help with getting 
more testers earlier in the release cycle.

On Thursday, October 23, 2014 4:25:46 AM UTC-4, Mattias Linnap wrote:
>
> My impression from the 1.7 release schedule was that there were many 
> release blockers found in RC stage, and RC with known bugs released because 
> of three combined reasons:
> * The release had a number of big new features, including app loading and 
> migrations.
> * In alpha and beta stages, the testers tend to be developers working on 
> the new release itself. Once RC is released, the release is seen as mostly 
> bug free, and many more Django users start using and testing the new 
> release in production on new greenfield projects and non-mission critical 
> sites where having the latest and greatest features is better than 
> stumbling on a few bugs. This production testing helps to discover many new 
> bugs, some of them release blockers.
> * Due to the high number of release blockers being discovered and fixed, a 
> new version identifier was released to simplify reporting new bugs in Trac 
> against the version that does or does not have these bugs.
>
> I know that the Django project tries to stay conservative and not 
> recommend betas and RCs for production use, since people might get upset if 
> their mission critical sites break. But I think the release and testing 
> process would benefit from the core developers giving their actual "best 
> guess" towards the stability of a beta and RC version, and let users judge 
> the acceptable risk of deploying it in production. There are plenty of 
> hobby projects, internal sites, and new not-yet-released sites out there 
> where a few days of downtime or hacking together workarounds isn't a big 
> problem, but for example data loss would be bad. With a description that is 
> less conservative than "never use it in production", more people might join 
> in on testing and reporting bugs before an RC.
>
> On Friday, 17 October 2014 22:48:18 UTC+3, Tim Graham wrote:
>>
>> I'd like to kickoff the discussion on the timetable and process for the 
>> 1.8 release. I am also volunteering to be the release manager.
>>
>> First, a retrospective on the 1.7 release with planned release dates and 
>> (actual):
>>
>> Jan. 20: alpha (Jan. 22)
>> March 6: beta (March 20)
>> May 1: RC (June 26)
>> May 15: final (Sept. 2)
>>
>> One observation I have is that each stage of the release does not really 
>> do a good job at accurately reflecting our belief about the quality of the 
>> code. For example, we have an "alpha" in order to have a major feature 
>> freeze, but we still allow a significant amount of minor features (3 months 
>> worth in the last release) such that the alpha and beta are hardly 
>> comparable. Likewise, we had little confidence that the "RC" would actually 
>> be released without further changes, but rather we needed to do the release 
>> in order to get to the stage where we would only backport release blocking 
>> bugs. Therefore, I am going to propose returning to a process that is 
>> closer to what's documented in the Release cycle docs [1]. The idea is to 
>> front-load all feature work to pre-alpha so that we can become more 
>> conservative with backports sooner.
>>
>> Here is my proposed schedule:
>>
>> Jan. 12: alpha
>>   - Feature freeze including minor features (minor features were allowed 
>> until beta in the past)
>>   - fork stable/1.8.x from master (in the past we forked after beta, but 
>> now that we'd no longer accept minor features after alpha, we'd need to 
>> fork sooner).
>>   - I picked this date since it is after the end of the year when I 
>> imagine many people are on holiday and therefore able to contribute more to 
>> open source.
>>   - Non-release blocking bug fixes may be backported at the committer's 
>> discretion after this date.
>>
>> Feb. 16: beta
>>   - Only release blocking bugs are allowed to be backported after this 
>> date.
>>   - Aggressively advertise it for testing
>>
>> March 16: release candidate
>>   - Hopefully a true release candidate. If there is still a consistent 
>> stream of release blockers coming in at this date; we'd release beta 2 to 
>> encourage further testing and push the release candidate date out ~1 month.
>>
>> March 30: final
>>   - Release a final as long as the release blocker stream is sufficiently 
>> low. If not, give an update about the status and make a plan as to how to 
>> proceed from there.
>>
>> On a related note, I believe we should give some guidance on our thinking 
>> regard LTS. Currently our docs say, "Django 1.4, supported until at least 
>> March 2015." If we adopt 1.8 as the next LTS, I propose to support 1.4 
>> until 6 months after 1.8 is released, which would be at least September 
>> 2015. Like 1.4, we'd advertise 

Re: 1.8 release planning

[Mattias Linnap]

My impression from the 1.7 release schedule was that there were many 
release blockers found in RC stage, and RC with known bugs released because 
of three combined reasons:
* The release had a number of big new features, including app loading and 
migrations.
* In alpha and beta stages, the testers tend to be developers working on 
the new release itself. Once RC is released, the release is seen as mostly 
bug free, and many more Django users start using and testing the new 
release in production on new greenfield projects and non-mission critical 
sites where having the latest and greatest features is better than 
stumbling on a few bugs. This production testing helps to discover many new 
bugs, some of them release blockers.
* Due to the high number of release blockers being discovered and fixed, a 
new version identifier was released to simplify reporting new bugs in Trac 
against the version that does or does not have these bugs.

I know that the Django project tries to stay conservative and not recommend 
betas and RCs for production use, since people might get upset if their 
mission critical sites break. But I think the release and testing process 
would benefit from the core developers giving their actual "best guess" 
towards the stability of a beta and RC version, and let users judge the 
acceptable risk of deploying it in production. There are plenty of hobby 
projects, internal sites, and new not-yet-released sites out there where a 
few days of downtime or hacking together workarounds isn't a big problem, 
but for example data loss would be bad. With a description that is less 
conservative than "never use it in production", more people might join in 
on testing and reporting bugs before an RC.

On Friday, 17 October 2014 22:48:18 UTC+3, Tim Graham wrote:
>
> I'd like to kickoff the discussion on the timetable and process for the 
> 1.8 release. I am also volunteering to be the release manager.
>
> First, a retrospective on the 1.7 release with planned release dates and 
> (actual):
>
> Jan. 20: alpha (Jan. 22)
> March 6: beta (March 20)
> May 1: RC (June 26)
> May 15: final (Sept. 2)
>
> One observation I have is that each stage of the release does not really 
> do a good job at accurately reflecting our belief about the quality of the 
> code. For example, we have an "alpha" in order to have a major feature 
> freeze, but we still allow a significant amount of minor features (3 months 
> worth in the last release) such that the alpha and beta are hardly 
> comparable. Likewise, we had little confidence that the "RC" would actually 
> be released without further changes, but rather we needed to do the release 
> in order to get to the stage where we would only backport release blocking 
> bugs. Therefore, I am going to propose returning to a process that is 
> closer to what's documented in the Release cycle docs [1]. The idea is to 
> front-load all feature work to pre-alpha so that we can become more 
> conservative with backports sooner.
>
> Here is my proposed schedule:
>
> Jan. 12: alpha
>   - Feature freeze including minor features (minor features were allowed 
> until beta in the past)
>   - fork stable/1.8.x from master (in the past we forked after beta, but 
> now that we'd no longer accept minor features after alpha, we'd need to 
> fork sooner).
>   - I picked this date since it is after the end of the year when I 
> imagine many people are on holiday and therefore able to contribute more to 
> open source.
>   - Non-release blocking bug fixes may be backported at the committer's 
> discretion after this date.
>
> Feb. 16: beta
>   - Only release blocking bugs are allowed to be backported after this 
> date.
>   - Aggressively advertise it for testing
>
> March 16: release candidate
>   - Hopefully a true release candidate. If there is still a consistent 
> stream of release blockers coming in at this date; we'd release beta 2 to 
> encourage further testing and push the release candidate date out ~1 month.
>
> March 30: final
>   - Release a final as long as the release blocker stream is sufficiently 
> low. If not, give an update about the status and make a plan as to how to 
> proceed from there.
>
> On a related note, I believe we should give some guidance on our thinking 
> regard LTS. Currently our docs say, "Django 1.4, supported until at least 
> March 2015." If we adopt 1.8 as the next LTS, I propose to support 1.4 
> until 6 months after 1.8 is released, which would be at least September 
> 2015. Like 1.4, we'd advertise LTS support for 1.8 for at least 3 years 
> after it's released with a decision on the next LTS to be made as we 
> approach that date.
>
> Feedback on the proposed schedule and handling of the LTS cycle would be 
> appreciated!
>
> If you have any major features you plan to shepherd for this cycle, please 
> ensure they are listed on the roadmap: 
> https://code.djangoproject.com/wiki/Version1.8Roadmap
>
> [1] 
> 

Re: 1.8 release planning

[Florian Apolloner]

On Saturday, October 18, 2014 1:17:58 AM UTC+2, Josh Smeaton wrote:
>
>  I was thinking along the lines of a one page common upgrade issues that 
> summarised the back-compat changes from the previous releases, separated 
> under each release header.
>

We already have on page per release for that. Duplicating this into yet 
another page doesn't seem to be that helpful.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd5b8f6a-1946-4b79-a850-51895ae6169b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 release planning

[Tim Graham]

If you are upgrading from 1.4, I would recommend going step by step through 
each intermediate Django version. I don't believe trying to upgrade 
straight away to 1.8 would be easier. I'd encourage anyone on 1.4 to start 
doing intermediate upgrades soon, so if there are still undetected 
regressions from 1.4, we can start solving them now.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0383fd1a-5d96-468f-8a92-7ca9eb9c709e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 release planning

[Josh Smeaton]

I was wondering when this discussion was going to happen - it's good to see 
some dates finally proposed, thanks Tim.

The LTS proposal is a good one. It should give people enough time (6 
months) to jump to the next LTS release. I also think that 1.8 should be a 
good candidate for LTS. Migrations and App Loading should have enough time 
to mature after a full release in the wild, and the proposed 1.8 features 
seem mainly focused on stability and compatibility rather than big sweeping 
public changes.

Perhaps it'd be a good idea to write a 1.4 - 1.8 migration guide to ease 
the transition between LTS releases? There have been some concerns raised 
on the ML lately about backwards compatibility and the difficulty in 
porting between versions. The current way of migrating to a new release 
involves reading each release note and checking your code base for those 
changes, and move one release at a time. Maybe a simplified all-in-one 
document that shows the most common backwards compatibility changes, and 
has guidance on how to address each of them.

On Saturday, 18 October 2014 06:48:18 UTC+11, Tim Graham wrote:
>
> I'd like to kickoff the discussion on the timetable and process for the 
> 1.8 release. I am also volunteering to be the release manager.
>
> First, a retrospective on the 1.7 release with planned release dates and 
> (actual):
>
> Jan. 20: alpha (Jan. 22)
> March 6: beta (March 20)
> May 1: RC (June 26)
> May 15: final (Sept. 2)
>
> One observation I have is that each stage of the release does not really 
> do a good job at accurately reflecting our belief about the quality of the 
> code. For example, we have an "alpha" in order to have a major feature 
> freeze, but we still allow a significant amount of minor features (3 months 
> worth in the last release) such that the alpha and beta are hardly 
> comparable. Likewise, we had little confidence that the "RC" would actually 
> be released without further changes, but rather we needed to do the release 
> in order to get to the stage where we would only backport release blocking 
> bugs. Therefore, I am going to propose returning to a process that is 
> closer to what's documented in the Release cycle docs [1]. The idea is to 
> front-load all feature work to pre-alpha so that we can become more 
> conservative with backports sooner.
>
> Here is my proposed schedule:
>
> Jan. 12: alpha
>   - Feature freeze including minor features (minor features were allowed 
> until beta in the past)
>   - fork stable/1.8.x from master (in the past we forked after beta, but 
> now that we'd no longer accept minor features after alpha, we'd need to 
> fork sooner).
>   - I picked this date since it is after the end of the year when I 
> imagine many people are on holiday and therefore able to contribute more to 
> open source.
>   - Non-release blocking bug fixes may be backported at the committer's 
> discretion after this date.
>
> Feb. 16: beta
>   - Only release blocking bugs are allowed to be backported after this 
> date.
>   - Aggressively advertise it for testing
>
> March 16: release candidate
>   - Hopefully a true release candidate. If there is still a consistent 
> stream of release blockers coming in at this date; we'd release beta 2 to 
> encourage further testing and push the release candidate date out ~1 month.
>
> March 30: final
>   - Release a final as long as the release blocker stream is sufficiently 
> low. If not, give an update about the status and make a plan as to how to 
> proceed from there.
>
> On a related note, I believe we should give some guidance on our thinking 
> regard LTS. Currently our docs say, "Django 1.4, supported until at least 
> March 2015." If we adopt 1.8 as the next LTS, I propose to support 1.4 
> until 6 months after 1.8 is released, which would be at least September 
> 2015. Like 1.4, we'd advertise LTS support for 1.8 for at least 3 years 
> after it's released with a decision on the next LTS to be made as we 
> approach that date.
>
> Feedback on the proposed schedule and handling of the LTS cycle would be 
> appreciated!
>
> If you have any major features you plan to shepherd for this cycle, please 
> ensure they are listed on the roadmap: 
> https://code.djangoproject.com/wiki/Version1.8Roadmap
>
> [1] 
> https://docs.djangoproject.com/en/dev/internals/release-process/#release-cycle
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b9ffc3f-e1b7-4176-b1be-ee18d7807c59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.