A New Django Release Cycle

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

A New Django Release Cycle

Abdullah Esmail
Hello everyone,

I am a web/mobile developer and I have been mainly using django since 2008 for web apps.
I'll throw my suggestion out there and see how you guys react to it.

I think the current release cycle for django is around 1 new version every 9 months. However, how about new versions of django are released yearly on a specific month of the year? Let's assume that django 1.5 is released on March 2013. This means django 1.6 should be expected on March 2014. With the current pace of new features and test releases, this will give django developers and contributors more than enough time to iron out more bugs and "rough edges." In addition, the support period for older versions will be a bit longer and more predictable which will make it more beneficial for developers/businesses (although it might add a slight burden to django core developers). This will also make it clearer when support for a specific version will be over so developers could have a clearer plan to upgrade.

Noticing this from django itself and other web frameworks, usually a 1-week period for a release candidate isn't really enough. It usually goes beyond the 1-week period and sometimes lasts for a month or more. What I suggest is the following release schedule:

1. Release version 1.x in March.
2. Developing and working on 1.(x+1) for 9 months.
3. Release 1.(x+1) beta in December.
4. Release 1.(x+1) RC1 in January.
5. Release 1.(x+1) RC2 in February.
6. Release 1.(x+1) final version in March.

I realize that it's hard to follow a release schedule like this especially for open source software, but I believe it's very doable.
django is one of the things that I love and do trust because of the high quality that it ships with and the evolutionary (rather than revolutionary) progress and features it introduces in every release. Having said that, I believe that such a release schedule will add more predictability and robustness to django which might very well lead to increased adoption.

This is just a suggestion.
Thank you very much for your efforts and for a lovely and great framework.

Regards,

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Russell Keith-Magee-4


On Fri, Jan 25, 2013 at 6:59 PM, Abdullah Esmail <[hidden email]> wrote:
Hello everyone,

I am a web/mobile developer and I have been mainly using django since 2008 for web apps.
I'll throw my suggestion out there and see how you guys react to it.

I think the current release cycle for django is around 1 new version every 9 months. However, how about new versions of django are released yearly on a specific month of the year? Let's assume that django 1.5 is released on March 2013. This means django 1.6 should be expected on March 2014. With the current pace of new features and test releases, this will give django developers and contributors more than enough time to iron out more bugs and "rough edges." In addition, the support period for older versions will be a bit longer and more predictable which will make it more beneficial for developers/businesses (although it might add a slight burden to django core developers). This will also make it clearer when support for a specific version will be over so developers could have a clearer plan to upgrade.

Noticing this from django itself and other web frameworks, usually a 1-week period for a release candidate isn't really enough. It usually goes beyond the 1-week period and sometimes lasts for a month or more. What I suggest is the following release schedule:

1. Release version 1.x in March.
2. Developing and working on 1.(x+1) for 9 months.
3. Release 1.(x+1) beta in December.
4. Release 1.(x+1) RC1 in January.
5. Release 1.(x+1) RC2 in February.
6. Release 1.(x+1) final version in March.

I realize that it's hard to follow a release schedule like this especially for open source software, but I believe it's very doable.
django is one of the things that I love and do trust because of the high quality that it ships with and the evolutionary (rather than revolutionary) progress and features it introduces in every release. Having said that, I believe that such a release schedule will add more predictability and robustness to django which might very well lead to increased adoption.

This is just a suggestion.
Thank you very much for your efforts and for a lovely and great framework.

Hi Abdullah,

There are at least two problems with what you have proposed.

Firstly, I think the core team would much rather move to more frequent, smaller releases, rather than "once a year" major releases. Having a larger number of smaller evolutionary releases means that features would get into production sooner, and the testing required on each release should be smaller (since the potential interaction of multiple new features will be lower).

Secondly, and more importantly, there's a resourcing problem. It's fine to say "lets always release in March". But what happens when March comes around, and there are still known bugs? We're all volunteers, and we don't have the power to compel anyone to work on anything. This means we're left with a dilemma -- either we ship a release with known bugs, or we delay the release. Personally, I'd much rather that a release slip by a couple of weeks, rather than ship something we know to be buggy.

I'm guessing your counterargument is that you're suggesting a much longer beta/RC cycle -- but that doesn't really change anything. Keeping something in RC for longer doesn't improve the result -- it just delays getting the code out into the field. While we get some great feedback during our beta and RC cycles, we *always* get more feedback *after* the release has been made final. Longer RC cycles won't increase the amount of testing, that a release gets -- it will just delay the release of production ready features, and force a longer period where the attention of the core team is split between fixing bugs in the next release, and new feature development on the release after that.

You even acknowledge that your proposed process will increase the maintenance burden on the core team. The core team already has a resourcing problem; we're not going to adopt a new release process that makes that problem worse.

So - thanks for the feedback, but honestly, I don't think our release schedule is constraining adoption of Django. If we want to improve adoption, there are many other things we could improve -- resources to convince a non-technical audience, for example. Small agile companies don't care about release schedules -- they'll use beta code if it's the best thing to get the job done. Large companies won't bet on anything that isn't already released with a proven track record. Knowing that the next Django release comes out on a particular date won't make Django more attractive to either audience.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Abdullah Esmail
Thanks Russell for your reply and explanation.
Now I know that it is much more involved and complicated than I originally thought.
Best of luck to you and the django team.
I'll do my best to help django in anyway possible :) (for me mainly fixing bugs/docs).

Regards,

On Friday, January 25, 2013 6:29:41 PM UTC+3, Russell Keith-Magee wrote:


On Fri, Jan 25, 2013 at 6:59 PM, Abdullah Esmail <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="fHqYbtLKSx4J">abdulla...@...> wrote:
Hello everyone,

I am a web/mobile developer and I have been mainly using django since 2008 for web apps.
I'll throw my suggestion out there and see how you guys react to it.

I think the current release cycle for django is around 1 new version every 9 months. However, how about new versions of django are released yearly on a specific month of the year? Let's assume that django 1.5 is released on March 2013. This means django 1.6 should be expected on March 2014. With the current pace of new features and test releases, this will give django developers and contributors more than enough time to iron out more bugs and "rough edges." In addition, the support period for older versions will be a bit longer and more predictable which will make it more beneficial for developers/businesses (although it might add a slight burden to django core developers). This will also make it clearer when support for a specific version will be over so developers could have a clearer plan to upgrade.

Noticing this from django itself and other web frameworks, usually a 1-week period for a release candidate isn't really enough. It usually goes beyond the 1-week period and sometimes lasts for a month or more. What I suggest is the following release schedule:

1. Release version 1.x in March.
2. Developing and working on 1.(x+1) for 9 months.
3. Release 1.(x+1) beta in December.
4. Release 1.(x+1) RC1 in January.
5. Release 1.(x+1) RC2 in February.
6. Release 1.(x+1) final version in March.

I realize that it's hard to follow a release schedule like this especially for open source software, but I believe it's very doable.
django is one of the things that I love and do trust because of the high quality that it ships with and the evolutionary (rather than revolutionary) progress and features it introduces in every release. Having said that, I believe that such a release schedule will add more predictability and robustness to django which might very well lead to increased adoption.

This is just a suggestion.
Thank you very much for your efforts and for a lovely and great framework.

Hi Abdullah,

There are at least two problems with what you have proposed.

Firstly, I think the core team would much rather move to more frequent, smaller releases, rather than "once a year" major releases. Having a larger number of smaller evolutionary releases means that features would get into production sooner, and the testing required on each release should be smaller (since the potential interaction of multiple new features will be lower).

Secondly, and more importantly, there's a resourcing problem. It's fine to say "lets always release in March". But what happens when March comes around, and there are still known bugs? We're all volunteers, and we don't have the power to compel anyone to work on anything. This means we're left with a dilemma -- either we ship a release with known bugs, or we delay the release. Personally, I'd much rather that a release slip by a couple of weeks, rather than ship something we know to be buggy.

I'm guessing your counterargument is that you're suggesting a much longer beta/RC cycle -- but that doesn't really change anything. Keeping something in RC for longer doesn't improve the result -- it just delays getting the code out into the field. While we get some great feedback during our beta and RC cycles, we *always* get more feedback *after* the release has been made final. Longer RC cycles won't increase the amount of testing, that a release gets -- it will just delay the release of production ready features, and force a longer period where the attention of the core team is split between fixing bugs in the next release, and new feature development on the release after that.

You even acknowledge that your proposed process will increase the maintenance burden on the core team. The core team already has a resourcing problem; we're not going to adopt a new release process that makes that problem worse.

So - thanks for the feedback, but honestly, I don't think our release schedule is constraining adoption of Django. If we want to improve adoption, there are many other things we could improve -- resources to convince a non-technical audience, for example. Small agile companies don't care about release schedules -- they'll use beta code if it's the best thing to get the job done. Large companies won't bet on anything that isn't already released with a proven track record. Knowing that the next Django release comes out on a particular date won't make Django more attractive to either audience.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Carlos Ribeiro
In reply to this post by Russell Keith-Magee-4
Russell,

New to the list (but using Django since 0.96). Got this thread today while searching on more information about the 1.5 delay. BTW, the blog post is ok, but could be a little bit more informative as for the reasons behind the delay.

I believe that Abdullah proposal has some merit. The value of timeboxes is well known; it gives a clear target to the project developers, and makes it much easier for your customers (which also happen to be developers) to make decisions about which version to use for a given project.

Of course, there are numerous problems which you point out, but I believe that many of them could be solved with improvements in coordination and discipline**. Of course, people are volunteers, and managing a schedule is hard. But it would be nice to do something in this regard.

The main problem for me is modularity. If something isn't ready by release date, it has to be removed - and for this to be possible, the base code has to be very modular. Features should be isolated in such a way that they could be turned on & off at will. That has implications too, nothing is easy (there's no free lunch). But it would be very good for everyone involved, in terms of planning.

That said, I'm not complaining. I'm just giving my 0.02 here.

** I'm aware that I'm new to the list and I'm also aware that it is much easier to say than to do. But it is possible.

Em sexta-feira, 25 de janeiro de 2013 13h29min41s UTC-2, Russell Keith-Magee escreveu:


On Fri, Jan 25, 2013 at 6:59 PM, Abdullah Esmail <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="fHqYbtLKSx4J">abdulla...@...> wrote:
Hello everyone,

I am a web/mobile developer and I have been mainly using django since 2008 for web apps.
I'll throw my suggestion out there and see how you guys react to it.

I think the current release cycle for django is around 1 new version every 9 months. However, how about new versions of django are released yearly on a specific month of the year? Let's assume that django 1.5 is released on March 2013. This means django 1.6 should be expected on March 2014. With the current pace of new features and test releases, this will give django developers and contributors more than enough time to iron out more bugs and "rough edges." In addition, the support period for older versions will be a bit longer and more predictable which will make it more beneficial for developers/businesses (although it might add a slight burden to django core developers). This will also make it clearer when support for a specific version will be over so developers could have a clearer plan to upgrade.

Noticing this from django itself and other web frameworks, usually a 1-week period for a release candidate isn't really enough. It usually goes beyond the 1-week period and sometimes lasts for a month or more. What I suggest is the following release schedule:

1. Release version 1.x in March.
2. Developing and working on 1.(x+1) for 9 months.
3. Release 1.(x+1) beta in December.
4. Release 1.(x+1) RC1 in January.
5. Release 1.(x+1) RC2 in February.
6. Release 1.(x+1) final version in March.

I realize that it's hard to follow a release schedule like this especially for open source software, but I believe it's very doable.
django is one of the things that I love and do trust because of the high quality that it ships with and the evolutionary (rather than revolutionary) progress and features it introduces in every release. Having said that, I believe that such a release schedule will add more predictability and robustness to django which might very well lead to increased adoption.

This is just a suggestion.
Thank you very much for your efforts and for a lovely and great framework.

Hi Abdullah,

There are at least two problems with what you have proposed.

Firstly, I think the core team would much rather move to more frequent, smaller releases, rather than "once a year" major releases. Having a larger number of smaller evolutionary releases means that features would get into production sooner, and the testing required on each release should be smaller (since the potential interaction of multiple new features will be lower).

Secondly, and more importantly, there's a resourcing problem. It's fine to say "lets always release in March". But what happens when March comes around, and there are still known bugs? We're all volunteers, and we don't have the power to compel anyone to work on anything. This means we're left with a dilemma -- either we ship a release with known bugs, or we delay the release. Personally, I'd much rather that a release slip by a couple of weeks, rather than ship something we know to be buggy.

I'm guessing your counterargument is that you're suggesting a much longer beta/RC cycle -- but that doesn't really change anything. Keeping something in RC for longer doesn't improve the result -- it just delays getting the code out into the field. While we get some great feedback during our beta and RC cycles, we *always* get more feedback *after* the release has been made final. Longer RC cycles won't increase the amount of testing, that a release gets -- it will just delay the release of production ready features, and force a longer period where the attention of the core team is split between fixing bugs in the next release, and new feature development on the release after that.

You even acknowledge that your proposed process will increase the maintenance burden on the core team. The core team already has a resourcing problem; we're not going to adopt a new release process that makes that problem worse.

So - thanks for the feedback, but honestly, I don't think our release schedule is constraining adoption of Django. If we want to improve adoption, there are many other things we could improve -- resources to convince a non-technical audience, for example. Small agile companies don't care about release schedules -- they'll use beta code if it's the best thing to get the job done. Large companies won't bet on anything that isn't already released with a proven track record. Knowing that the next Django release comes out on a particular date won't make Django more attractive to either audience.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Aymeric Augustin
Le 25 janv. 2013 à 11:59, Abdullah Esmail <[hidden email]> a écrit :

I realize that it's hard to follow a release schedule like this especially for open source software, but I believe it's very doable.

I agree that it should be doable in theory, and I strongly support predictable schedules. Obviously, in practice, in spite of the core team's efforts, it doesn't happen.

There isn't any corporate backing behind Django and no one gets paid to make releases happens. Besides, active contributors are comfortable with running on master. As a consequence, the incentive for taking the responsibility of making a release on a given date is low. Solving that problem might to more harm than good!



Le 27 janv. 2013 à 17:47, Carlos Ribeiro <[hidden email]> a écrit :

Of course, there are numerous problems which you point out, but I believe that many of them could be solved with improvements in coordination and discipline**. Of course, people are volunteers, and managing a schedule is hard. But it would be nice to do something in this regard.

FYI I tried to do exactly that for 1.4 and 1.5 and I failed. Someone else is welcome to try again for 1.6.

One thing I haven't attempted is to extend the "coordination and discipline" beyond the core team to the entire community.

As a very long time user of Django, how much testing are you giving to alpha / beta / RC releases within two weeks? How many regressions have you reported? How many patches for release blockers have you written? What could increase your contributions?

The main problem for me is modularity. If something isn't ready by release date, it has to be removed - and for this to be possible, the base code has to be very modular. Features should be isolated in such a way that they could be turned on & off at will. That has implications too, nothing is easy (there's no free lunch).

I'm not sure this can work. You cannot simply rollback the fix for a data loss bug, because that's considered a release blocker; and such fixes often create subtle regressions. For a more extreme example, you cannot rollback the unicode_literals patch that was the first step to Python 3 support but created half a dozen regressions (which is impressively few considering the scope and the size of that patch).

Best regards,

-- 
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Carlos Ribeiro
On Sun, Jan 27, 2013 at 9:26 PM, Aymeric Augustin <[hidden email]> wrote:
There isn't any corporate backing behind Django and no one gets paid to make releases happens. Besides, active contributors are comfortable with running on master. As a consequence, the incentive for taking the responsibility of making a release on a given date is low. Solving that problem might to more harm than good!

That's a real problem, agreed!
 
Le 27 janv. 2013 à 17:47, Carlos Ribeiro <[hidden email]> a écrit :
Of course, there are numerous problems which you point out, but I believe that many of them could be solved with improvements in coordination and discipline**. Of course, people are volunteers, and managing a schedule is hard. But it would be nice to do something in this regard.

FYI I tried to do exactly that for 1.4 and 1.5 and I failed. Someone else is welcome to try again for 1.6.

Sincerely sorry... 

One thing I haven't attempted is to extend the "coordination and discipline" beyond the core team to the entire community.

As a very long time user of Django, how much testing are you giving to alpha / beta / RC releases within two weeks? How many regressions have you reported? How many patches for release blockers have you written? What could increase your contributions?

Ok, you got me, I'm not a contributor, and over the past years I used Django mostly for my personal projects, which are a few and mostly private (not open source). However, I feel qualified to contribute with a few ideas and comments, based on my previous experience. Of course, you can (and should) take it with a (large) graind of salt.

I was very active in the open source scene several years ago. For example, I was a core developer of CherryPy for a couple years, and helped advance some concepts (and implementations) that were quite advanced at the time, including filters - that were kind of the same as the middleware that Django uses now - and the ability to use generators to stream content. If I'm not mistaken, that was in 2004, nine years ago, and CherryPy was the first Web framework to support it.

The main problem for me is modularity. If something isn't ready by release date, it has to be removed - and for this to be possible, the base code has to be very modular. Features should be isolated in such a way that they could be turned on & off at will. That has implications too, nothing is easy (there's no free lunch).

I'm not sure this can work. You cannot simply rollback the fix for a data loss bug, because that's considered a release blocker; and such fixes often create subtle regressions. For a more extreme example, you cannot rollback the unicode_literals patch that was the first step to Python 3 support but created half a dozen regressions (which is impressively few considering the scope and the size of that patch).

Please don't take me wrong, but most of the times this is caused by the very lack of modularity that I mentioned. If removing a feature causes subtle regressions, is either because the patch touches too many parts of the code (in other words, its effect is not contained into a single module), or because code is too tightly coupled (modules depend on each other in subtle ways). Of course there's always some chance that something HAS to be fixed before release. But that sould be the exception, and not the norm - as it was the case with the unicode literals, which *is* an clear exception (migrating to Python 3 is really a huge task!).

As a closing remark, I'm not really familiar with Django code base to talk about specifics. I'm just adding a voice to note that having fixed date releases could, and should, be a goal. But I'm in no position to actually argue any more than any other casual user.

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Russell Keith-Magee-4

On Mon, Jan 28, 2013 at 7:49 AM, Carlos Ribeiro <[hidden email]> wrote:
On Sun, Jan 27, 2013 at 9:26 PM, Aymeric Augustin <[hidden email]> wrote:
There isn't any corporate backing behind Django and no one gets paid to make releases happens. Besides, active contributors are comfortable with running on master. As a consequence, the incentive for taking the responsibility of making a release on a given date is low. Solving that problem might to more harm than good!

That's a real problem, agreed!
 
Le 27 janv. 2013 à 17:47, Carlos Ribeiro <[hidden email]> a écrit :
Of course, there are numerous problems which you point out, but I believe that many of them could be solved with improvements in coordination and discipline**. Of course, people are volunteers, and managing a schedule is hard. But it would be nice to do something in this regard.

FYI I tried to do exactly that for 1.4 and 1.5 and I failed. Someone else is welcome to try again for 1.6.

Sincerely sorry... 

One thing I haven't attempted is to extend the "coordination and discipline" beyond the core team to the entire community.

As a very long time user of Django, how much testing are you giving to alpha / beta / RC releases within two weeks? How many regressions have you reported? How many patches for release blockers have you written? What could increase your contributions?

Ok, you got me, I'm not a contributor, and over the past years I used Django mostly for my personal projects, which are a few and mostly private (not open source). However, I feel qualified to contribute with a few ideas and comments, based on my previous experience. Of course, you can (and should) take it with a (large) graind of salt.

I was very active in the open source scene several years ago. For example, I was a core developer of CherryPy for a couple years, and helped advance some concepts (and implementations) that were quite advanced at the time, including filters - that were kind of the same as the middleware that Django uses now - and the ability to use generators to stream content. If I'm not mistaken, that was in 2004, nine years ago, and CherryPy was the first Web framework to support it.

The main problem for me is modularity. If something isn't ready by release date, it has to be removed - and for this to be possible, the base code has to be very modular. Features should be isolated in such a way that they could be turned on & off at will. That has implications too, nothing is easy (there's no free lunch).

I'm not sure this can work. You cannot simply rollback the fix for a data loss bug, because that's considered a release blocker; and such fixes often create subtle regressions. For a more extreme example, you cannot rollback the unicode_literals patch that was the first step to Python 3 support but created half a dozen regressions (which is impressively few considering the scope and the size of that patch).

Please don't take me wrong, but most of the times this is caused by the very lack of modularity that I mentioned. If removing a feature causes subtle regressions, is either because the patch touches too many parts of the code (in other words, its effect is not contained into a single module), or because code is too tightly coupled (modules depend on each other in subtle ways). Of course there's always some chance that something HAS to be fixed before release. But that sould be the exception, and not the norm - as it was the case with the unicode literals, which *is* an clear exception (migrating to Python 3 is really a huge task!).

Unicode-literals is an extreme example, but the same problem exists on much smaller issues too, and it has nothing to do with coupling or cohesion between modules. Consider: Someone adds a fix to the ORM system that corrects one edge case of select_related behavior when nullable joins are involved. Someone else adds a fix around the way that nullable joins are interpreted for aggregates. At some point, a regression is found. The problem is tracked back, and found to be due to the select_related fix. However, you can't just roll back that fix, because the two patches overlap. It won't be a clean rollback. So by rolling back, you introduce the possibility of entirely *new* bugs, caused by the rollback. You options are:

 a) Rollback *both* patches (and any other patches affected by rolling back those patches), resulting in a release with known bugs with partial known solutions

 b) Roll back the select_related patch and spend time trying to validate that the changes to the aggregation patch are correct

 c) Spend time fixing the underlying problem with the select_related patch

Of those three options, options b and c take time; option a results in a situation where potentially large numbers of bugs need to be reopened.
 
As a closing remark, I'm not really familiar with Django code base to talk about specifics. I'm just adding a voice to note that having fixed date releases could, and should, be a goal. But I'm in no position to actually argue any more than any other casual user.

And a fixed date *is* our goal. We just don't say publish "March 1" as our annual release date. Go back into the archives. We have historically aimed at roughly 9 month release cycles - 3 months of large feature development, 3 months of small feature and bug work, and 3 months of stabilising. We've published that schedule, saying we're aiming at a date. Then reality rears it's ugly head, and timelines slip.

Then we have two options:

 * Release on a fixed date, with known problems

 * Delay the release date.

If you delay the release date, you're then faced with a new problem -- do you delay the *next* release as well, to make sure you have a full release timeline? 

Admittedly, this is less of a problem if the release schedule is longer, but it still needs to be taken into account. And as I indicated earlier, the core team would like to move to a shorter, faster release schedule, specifically to reduce the likelihood of large schedule overruns.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: A New Django Release Cycle

Carlos Ribeiro
On Sun, Jan 27, 2013 at 11:03 PM, Russell Keith-Magee <[hidden email]> wrote:
Please don't take me wrong, but most of the times this is caused by the very lack of modularity that I mentioned. If removing a feature causes subtle regressions, is either because the patch touches too many parts of the code (in other words, its effect is not contained into a single module), or because code is too tightly coupled (modules depend on each other in subtle ways). Of course there's always some chance that something HAS to be fixed before release. But that sould be the exception, and not the norm - as it was the case with the unicode literals, which *is* an clear exception (migrating to Python 3 is really a huge task!).

Unicode-literals is an extreme example, but the same problem exists on much smaller issues too, and it has nothing to do with coupling or cohesion between modules. Consider: Someone adds a fix to the ORM system that corrects one edge case of select_related behavior when nullable joins are involved. Someone else adds a fix around the way that nullable joins are interpreted for aggregates. At some point, a regression is found. The problem is tracked back, and found to be due to the select_related fix. However, you can't just roll back that fix, because the two patches overlap.

Let's talk "in principle"... if the two patches overlap, then you have coupling, like it or not. A truly modular design wouldn't have this kind of coupling. Of course, that's something that only happens in the ideal world; in the real world things are not that easy, and in many cases (for whatever reason) it's not doable at all. But again, that (minimizing coupling) should be one of the goals, and whenever you detect that it happened (an unfortunate coupling like you mentioned), it should be possible to devise some way to minimize the coupling as part of the solution. That minimizes the coupling over time.

That said, thanks for your patience, I don't want to drag everyone into a fruitless discussion. Thanks also for all the hard work with Django - and my sincere wishes of a better 1.6 cycle for everyone!

--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: [hidden email]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.