How do features get decided for a release?

[Cody Scott]

I know that I can look at the 1.7 release notes to see what is to come in the next release.

How do django developers decide what features to work on?

Is there a minimum time between releases?

Is there a minimum quota for fixed bugs for a release?

Is there ever a poll to see which features the community wants?

Is there another way that developers get what the community wants?

[Curtis Maloney]

Hi Cody,

I suspect many of your questions may be answered in the documentation here:

https://docs.djangoproject.com/en/1.5/internals/release-process/

Here's some comments from my experience with using django since its initial release, and recently making a concerted effort to submit code.

On 24 October 2013 13:45, Cody Scott <cody.j....@gmail.com> wrote:

I know that I can look at the 1.7 release notes to see what is to come in the next release.

How do django developers decide what features to work on?

I don't believe there's a specific roadmap for features.

If someone writes a patch, it has a great chance to make it in.  It's as simple as that (or, can be).

Is there a minimum time between releases?

From the link above:

"Minor release (1.1, 1.2, etc.) will happen roughly every nine months"

 

Is there a minimum quota for fixed bugs for a release?

Critical bugs [such as data loss or crashes] and security fixes will warrant rapid release of a Micro version.

Between Minor versions, they can vary a lot.

 

Is there ever a poll to see which features the community wants?

See the section "Phase one: feature proposal"

 

Typically, a feature/ticket with code has a great chance to make it it.  That said, a number of my changes that have made it into 1.7 were proposed and accepted in a matter of a few days.

Is there another way that developers get what the community wants?

Open a ticket, provoke discussion on the django-dev mailing list, and champion the ticket -- either by writing the code yourself, or finding someone to do it for you.

As the release cycle notes say "working code trumps grand design" 

--

Curtis

[Russell Keith-Magee]

Hi Cody,

Django development -- like most open source development -- doesn't happen in the same way as commercial development. We don't sit down, decide features that we want, develop a plan, track progress against that plan, and deliver those features. 

We're an entirely volunteer driven organisation, and the thing about volunteers is that you don't have any carrots or sticks to drive the development process. I can't compel anyone to work on anything -- and if I punish people for not meeting my expectations, I'll probably find that my volunteers go away pretty quickly.

Open source development means you have to recalibrate your thinking around how software gets developed.

There isn't a minimum time between releases. We put out releases when we need to. We've historically put out point releases on a roughly annual timeframe, because that's matched our rate of development (and takes into account how much ; however, the 1.6 release is on track to be a 7 month development process.

There isn't a minimum quota of bugs. The bugs that get fixed are the bugs that people provide patches for, and the core team can find sufficient time to review and commit.

There isn't any sort of formal process for deciding what will be added. The features that are added are the features that volunteers feel sufficiently motivated to drive through the development process. Sometimes this means that features stay on the todo list for a long time, and sometimes it means that a feature goes from concept to completion in a matter of weeks.

In essence, the community is getting *exactly* what it wants… in the sense that anyone who wants something bad enough is able to put in the time to develop a feature, and will drive it to completion.

So - to answer the specific question -- Django 1.6 is about to be released (we just pushed our release candidate, which means the final is a matter of a week or so away). Django 1.7 is currently in feature development. The only features we can guarantee will be in Django 1.7 are those that we've already committed (most notably, migrations, and a couple of others that are listed in the release notes). I can take a guess at a couple of others that are *likely*, based purely upon the work that I myself am doing, and what I've heard other core team members talking about. However, until any of that code is committed, it's all speculative.

Yours,

Russ Magee %-)

[Cody Scott]

How do you decide which version to put a feature in?

Why wasn't migrations in 1.6?

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/M6ny4k476dk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAJxq84-agEjQE35sUUyj%3D4WKAnBbovaJKG8Ag6V35%2B%3DAdMBQBQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Marc Tamlyn]

That's to do with the date a feature lands. Migrations isn't completely feature complete or totally stable yet - squashing migrations actually landed in the master branch this week.

When we release the beta, the version goes into feature freeze so only minor bug fixes and any critical issues get merged into that branch - no new features (like migrations).

With migrations being such a large project, Andrew deliberately waited until the feature freeze to merge it so as to give people as long as possible to find issues.

So short answer - there's normally no decision it's just a case of 'is it before the date of the beta'.

Marc

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 django-develop...@googlegroups.com.

To post to this group, send email to django-d...@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/CAFUqbeCtP643hqk5TpP341xBdqiMxnpeAKhNSR%3DeoLXaF5mYJQ%40mail.gmail.com.