New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Django-extensions 1.0 or 0.10 ? #241

Closed
trbs opened this Issue Sep 19, 2012 · 18 comments

Comments

Projects
None yet
9 participants
@trbs
Member

trbs commented Sep 19, 2012

As a community project I think it would be fun to ask, you the community, about your input to this question.

Should the next release of Django Extensions be 1.0 or 0.10 ?

@ghost ghost assigned trbs Sep 19, 2012

@supercodepoet

This comment has been minimized.

supercodepoet commented Sep 19, 2012

I would go with 1.0

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 19, 2012

Both are great, I would say 1.0 if it support python 3k (with django 1.5 beta) or 0.10 if it doesn't.

@wo0dyn

This comment has been minimized.

wo0dyn commented Sep 19, 2012

+1 → I would go with 1.0 (@supercodepoet)

@jezdez

This comment has been minimized.

Contributor

jezdez commented Sep 19, 2012

Definitely 1.0.

The 0.XX version scheme doesn't make sense to me as it would seem to me like the 10th version of an app that isn't really considered "stable". But django-extensions is used in production for years, so I think a 1.0 is more than overdue.

@VMitov

This comment has been minimized.

VMitov commented Sep 19, 2012

+1 for leaving 1.0 for the version that will support 3k

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 19, 2012

If I suggest to report 1.0 for 3k support, it's for two main reasons:

  • This change will require to review all the code and will be expected with django 1.5/1.6
  • Even if it's not an API break, it will mark in an easy to remember way which version does or doesn't support 3k and will change a bit commit rules as it will be tested on python 3.
@twigs

This comment has been minimized.

Contributor

twigs commented Sep 19, 2012

+1 for version 1.0

@jezdez

This comment has been minimized.

Contributor

jezdez commented Sep 19, 2012

@Christophe31 I agree with your arguments, only that it's perfectly fine to do a 2.0 release then. The code in use now is production ready, so a 1.0 makes sense for that.

Also, Django 1.5 will only have experimental support for Python 3.X (bugs are expected, no backwards compatibility guarantee, etc) and is planned to be released at the end of the year.

The first official release with Python 3 support is 1.6 some time next year. I'm not sure if django-extensions should wait with its 1.0 till then.

@wo0dyn

This comment has been minimized.

wo0dyn commented Sep 19, 2012

Chrome's version is 21.0.1180.89 so django-extensions' version might at least be 1.0! 😉
Ok, not helping…

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 19, 2012

I don't really like number version which grow too fast without noticeable changes. We'll always be able to increase it in the future. The other way is less common and may disturb package managers. I don't like to go too fast on a one way street.

Many software stayed in 0 branch for years even if they were stable (like VLC).

Saying that 1.0 is a way to mean production ready because 0.9 is already used in production. It's like adding "For kids" on a toy box because it's used mainly by kids.

But what ever, 1.0 may be fine. But if we go too fast we won't be able to choose new numbering.

A numbering method which may sound neat would be take the greatest django version officially supported then a release number. ex: 1.4.2

I don't ask for this numbering but if we switch to high number too quickly we will not able to change.

note: in a meritocracy, I only committed a 2 chars fix so don't take my words too seriously, I expose my opinion but the best choice will be the one of core maintainers.

@trbs

This comment has been minimized.

Member

trbs commented Sep 19, 2012

@Christophe31 Was actually thinking about the same thing. Outlined a proposal at http://trbs.net/blog/2012/09/20/django-extensions-versioning-follow-django/

Nice thing about that kind of version structure is that it would be very clear for users which version to use.
As well as that we can follow Django's own well defined progress for deprecating and removing compatibility for older Django and Python versions.

@juanpex

This comment has been minimized.

juanpex commented Sep 20, 2012

+1 on version 1.4 now, and then 1.5

follow Django :)

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 20, 2012

The counterpart with this numbering exists. Pip is great and allow to get a given version by specifying first numbers.
Will community expect extra work of maintaining branches for different django version?

If we link our-self too tightly with django version, it may be ambiguous that this branch is also meant for the previous release of django and may work without modification on the next one.

I'm searching counter parts because I'm TrollMaster.

It would be rather obvious that it means "tested against X.X django version which is the most officially supported release"

What do you think @jezdez ?

note:I seen my nickname in planet django this morning! Hmm, good lord ^^.

@jezdez

This comment has been minimized.

Contributor

jezdez commented Sep 20, 2012

@trbs I'm -1 on the follow Django pattern, I've seen it with other Django packages (e.g. grappelli) and they failed in always matching the major version. There is precedence in having a sane increasing version number, PEP 386 for example is the one that the Python community agreed to after years of usage. It requires at least a X.Y version, but commonly used is the form X.Y.Z where X is a major, Y a minor and Z a bugfix release number. This is also used by Python itself. I'm strongly urging you to follow the rest of the Python community with that scheme.

@Christophe31 I disagree that the "other way is less common and may disturb package managers". I'm one of the authors of pip and I can guarantee you that it's perfectly capable of handling increasing version numbers.

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 20, 2012

The other way, I meant decreasing the version number for a new release.
That's also why I was talking about a one way road. If we bump release number too fast we close our self new numbering system. For exemple, Firefox and chrome by bumping so fast version number can't use the one of the ecmascript implementation or the ubuntu numbering style...

Folowing django was not an idea I considered really seriously, but an argument to don't bump too fast. I didn't know that grapelli numbering was this way and that it was a problem for them.

So I meant by running too fast you will not be able to see what you may be missing.

Nevertheless, I strongly agree on your argument about PEP 386 but as there are no major changes in future release, it still should be 0.10 from my point of view... And keeping 1.0 for py3k compliant release.

(If what I say is not clear, I'm sorry about that, I read English with ease but when it come to write, I sometime remember that French is my native language.)

@alphacc

This comment has been minimized.

alphacc commented Sep 20, 2012

Putting my RPM packager hat.
Using 1.4.X is fine until you go over 1.4.10.
Yum will always think 1.4.10 < 1.4.2 and won't upgrade.
My 2 cents.

@Christophe31

This comment has been minimized.

Contributor

Christophe31 commented Sep 20, 2012

You mean yum consider packages number as a kind of creepy floats?! o_0

@alphacc

This comment has been minimized.

alphacc commented Sep 20, 2012

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2005-12/msg00397.html
This still true for RHEL5 and RHEL6.
I don't know what the status with Fedora.

@trbs trbs closed this Oct 22, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment