That said, he's got a valid point. We've been delaying a release
waiting on newforms-admin for quite some time, but unfortunatly we
don't have a lot of folks working on that branch. Brian, Karan, and
Joseph are certainly doing what they can, but there's quite a bit of
work to be done there.
As I see it, we've got three options:
* Wait for newforms-admin to be done, merge it, and release 1.0 (well,
a series of beta/rcs, then final). This has been "plan A" all along.
* Release an interim release right away to respond to this supposed
"outcry" for a release. I've been opposed to this all along because I
don't the quality of something released just to get folks to shut up
will be all that high. A snapshot with an "official" number will
likely do more harm than good.
Which brings me to a middle ground I'd like to propose. I've been
meaning to propose this for a few weeks, but haven't gotten around to
writing it up fully; here's the half-assed proposal which I can follow
with more details if there are questions:
* Start a "train release" schedule: schedule a couple of 1.0 betas, a
rc or two, and then a final release. Features that are done by the
dates get released, those that aren't, don't. Make these dates
aggressive but not crazy. And -- here's the controversial part -- make
newforms-admin an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?
Jacob
This is similar to the Ubuntu release schedule -- release every 6
months and whatever is done/stable at the time makes it, otherwise
things wait for the next release (which isn't too far out).
+1 from me, and it provides for a little motivation since there is a
target date on the horizon.
-Rob
Jacob Kaplan-Moss wrote:
> For the record, and if the author of this blog post is reading: I
> can't stand the passive-aggressiveness of making a rant on your blog
> and waiting for us to read it. I wish this had been brought up here
> instead of trying to drum of some supposed "outcry" for a new release.
I can see how one could percieve it as such, however there was no harm
intended with my blog post.
It was merely a case of trying to establish an argument as to why I
would like to see more frequent releases and documenting some of the
unfortunate side effects of the current model.
I myself have been very surprised as to how much fuzz this blog post has
generated. But on the other hand, I think the discussion is healthy for
the project. The users gets to express their views and hopefully the
Django team listens.
[...]
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an "optional" part. If it's done, awesome; if not,
> include it in the next release. The current admin has some bugs, yes,
> but it's usable enough. As long as we advertised that it's on the way
> out we shouldn't have too much trouble.
That sounds like a great idea. As long as there is a schedule I think
most of "us" would be satisfied and shut up ;-)
That said; maybe now is the time for me to start poking around and see
if I can help out with anything other than the occasional patch a couple
of times a year.
Regards,
--
Christian Joergensen
http://www.technobabble.dk
+1. I think this needs to happen to the Django release cycle in
general. I think it is a good way to keep developers motivated to
complete features and continually get releases out the door. The
Django trunk needs to be place were we can dump these features and get
constant feedback from the community of those who want to keep up with
the bleeding edge.
newforms-admin only has a few "absolutely have to have done before a
merge" items IMO. The rest of the nfa-blockers can be dealt with on
trunk. It is already a big enough backward-incompatible change that
people will be having to do the changes or wait to find time. I think
that newforms-admin needs to land as soon as possible. The whole idea
of newforms-admin has been accomplished. The admin is using newforms.
There are a ton of hooks. The rest can be worked on with the full
Django core team and the many contributors in the community.
Brian Rosner
http://oebfare.com
It does indeed take time to roll a release. More importantly, issuing
a release means that we -- the Django team -- make a promise of
support for it, which is the important part and the part that
ultimately ends up eating much more time. It's also the part people
tend to forget about when they start asking why we don't just roll a
new release whenever they think we should.
We've stated in the past that the next official supported release of
Django will be 1.0. I think that's a good idea, and I personally think
we ought to stick to it; the things we've outlined for 1.0 are
significant enough that incrementally pushing releases before that
will do more harm (in terms of presenting a constantly-moving target
to the people who believe releases mean long-term stability) than
good.
And, really, that's the catch-22: if we released much more frequently
than we do now we'd likely get just as many complaints, only from a
different group of folks. As has been stated before, having people
upgrade from 0.96 to a 0.97 release based on current trunk would
subject those people to a fair number of required changes; having them
upgrade at each step along the way to 1.0 would impose that on them
repeatedly. That's not something I'd be comfortable with; I'd rather
try to minimize the number of releases which involve significant
end-user changes. The ideal is to just do it once, and then we're at
1.0 with a compatibility guarantee toward the future.
So personally, I think discussion of more aggressive release schedules
should happen once we're *at* 1.0, with a hard promise of stability.
Once we're there, more frequent releases (say, to add new features or
to expand django.contrib) make a whole lot more sense to me. But right
now as we're working through the changes necessary to reach 1.0, I
don't see much good in diverting that goal to produce interim packages
that will, in turn, increase our support workload.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
vote(-(sys.maxint))
Newforms-admin needs to get done. Putting it off from the first couple
betas or RCs will just increase the temptation to put it off further,
so what we should do is identify anything that's slowing it down and
work to resolve that. If that means organizing a sprint or two on it
and then doing a trunk merge to get more eyeballs on the code, then
let's do that instead.
-1
I'm not sure blessing it with a number does much but pander to
folks that are scared to make a tough call:
Use 0.96: blessed with a magic number, but old and not much like
1.0 will be
or use Trunk: suggested (but not blessed with a number), much
closer to like 1.0 will be, and still some changes to be expected
when new-forms hits.
Blessing an interim release means supporting it...namely without
the features that have been planned for 1.0 and adds confusion as
to what comprises "Django 1.0"
If Django 1.0 should have NFA and QSR, anything short of that
should not be called 1.0, IMHO.
Eric Florenzano wrote:
> -0
>
> I disagree about the newforms-admin part being optional. Right now
> the admin is great, but it's tightly coupled with the models. With
> newforms-admin, there's not only a great increase in the power of the
> admin app itself, but it's also a demonstration of best practices for
> creating generic apps with Django. Also, if a 1.0 got released with
> oldforms-admin, there will be the inevitable media fanfare, so imagine
> the books, tutorials, articles, etc. that will be written which
> referencing the old ways.
I add my support to Eric's reasoning.
-tim
Where I work we use 0.96 (though I use trunk on my personal projects).
We use 0.96 because we have up to 12 separate Django projects
rotating through at a time and all at various phases of development.
We don't have the resources to continuously update all of them to
trunk and fix the various backward incompatible changes that might
crop up, and each one can't be on its own trunk release or trying to
assemble any sort of library would be a nightmare. Not even
mentioning having to support various Django releases on our production
servers. So we're stuck on 0.96 until 1.0 comes along.
Not so much a tough call to pick 0.96 in our case, but I'm jealous at
the more than 1 year of great features in Django trunk.
-Rob
There's really nothing we can do that'll make those folks happy, so
I'd vote for continuing on the path toward 1.0.
In that environment, perhaps you should work on tools and techniques
to make automated porting work. Otherwise, you're going to have a
painful legacy problem.
As someone who would benefit from NFA and has done nothing to help it
along, I'd be happy to contribute to an NFA-focused sprint.
On Sat, Jun 7, 2008 at 9:38 PM, James Bennett <ubern...@gmail.com> wrote:
>
> And for the record, I do think that *post-1.0* we should do more
> frequent releases, because it'll be quite a bit simpler to do at that
> point. I just think that right now it's not really worth the trouble;
> the same people who currently complain that they have to use a
> packaged release but want a post-0.96 feature would just turn around
> and complain that they need stability and wish we'd stop pushing
> releases with big changes in them.
>
> There's really nothing we can do that'll make those folks happy, so
> I'd vote for continuing on the path toward 1.0.
>
While I personally can go either way on this particular issue -- i.e.
I see the point of regular releases, timed release, or waiting until
feature complete for 1.0 -- I do think James is tending toward the
cynical on this a bit. No offense meant to James.
I do agree that release numbers often have too much weight attributed
to them, but there really is *some* value in them. If nothing else,
you can build community around a release in a way that you can't
running against trunk. And also, I think the larger point of some of
this discussion is that it's been over a year since .96, and if it's
still going to be a while to 1.0, some feel an intermediate release
could be useful.
Again, I understand limited developer resources, and I get open source
projects having to put effort where is most practical. I think that
argument is enough, without trying to lump everyone together who would
like to see another release in the near term as "haters" who are going
to be disappointed no matter what happens. I know those people exist,
but I don't everyone who expresses concerns or questions is
necessarily that kind of person.
Cheers,
deryck
--
Deryck Hodge
http://www.devurandom.org/
-1, for now at least. IMHO, we simply cannot release a v1.0 that has
oldforms in it, and without the merge of newforms-admin, we're not
going to be able to do that.
Newforms-admin is the last piece in an important cycle of refactoring
that has been going on since Django was originally open sourced.
Magic-removal cleaned up model defintions, the query syntax, and some
model loading issues. Queryset-refactor cleaned up the query
internals. Newforms cleaned up manipulator/oldforms. Newforms-admin
completes the newforms transition.
Once NFA is done, I can't really think of an area of Django that will
require wholesale change - there are lots of improvements that can be
made, but they should be incremental, rather than massive. For those
sorts of changes, train-schedule releases are ideal. However, we need
a solid foundation to work on.
As for getting the work done - I've been distracted for most of this
year, but I'm starting to get some free time again. I have been
working though a backlog of little tickets. However, most of these are
minor feature enhancements. I'm happy to put those on hold and work on
newforms-admin instead so we can get this monkey off our backs.
Yours,
Russ Magee %-)
+1 for early merging. Merging qs-rf helped (forced :-) ) many people to
catch many bugs that won't ever be found on the branch due to lack of
attention.
> Fortunately, the trunk is stable (thank you!).
I think what people are missing most here is that this statement is
moderately inaccurate. Since QSRF, there have been a significant
number of data-fetching related tickets that are relatively easy to
hit that have not yet been resolved. This is no one's fault, Malcolm
had real life come up, and there are very few people capable of
replacing him right now. This is also not to disparage Django's
quality of trunk code (which is very high), QSRF was a *very* large
merge, it was impossible that things were not going to need review
after release to such a wide audience.
I'm attempting to pick up the slack at least in part, but we have
several tickets that range from easy to identify and solve to rather
complicated for things that are relatively common database use cases.
Here's a smattering of those tickets (I do not promise that I have
verified every one of these, just some, the rest were from a grazing
of the ticket system for things that looked similar to problems I've
encountered):
http://code.djangoproject.com/ticket/7378 - Reverse relationship
ignores to_field (in another setting)
http://code.djangoproject.com/ticket/7372 - queryset intersection
either returns wrong result or raises KeyError depending on order
(after queryset-refactor merge)
http://code.djangoproject.com/ticket/7371 - Missing FROM table from
autogenerated SQL throws error
http://code.djangoproject.com/ticket/7369 - ForeignKey non-null
relationship after null relationship on select_related() generates
invalid query
http://code.djangoproject.com/ticket/7367 - Cannot have non-primary-
key OneToOneField to parent class
http://code.djangoproject.com/ticket/7330 - Filtering on multiple
indirect relations to same table gives incorrect SQL
http://code.djangoproject.com/ticket/7277 - after queryset refactor,
specifying > 2 OR'ed conditions that span many-to-many relationships
returns broken SQL
http://code.djangoproject.com/ticket/7125 - Multiple ForeignKeys to
the same model produces wrong SQL statements.
Now, I'm putting my money where my mouth is, and am working to
understand the flow of the internal query API so that I can generate
patches for most of these tickets, as something we're working on over
here requires some deep integration into the SQL layer (better
selectability on OneToOneFields). That aside, now that QSRF is
getting a real fleshing-out and all these reports are trickling in, I
think it would be a bad idea to stamp a version right now until either
someone can step up and fill Malcolm's shoes as a queryset maintainer,
or he becomes available once again from real life.
Thanks,
George
The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0. If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.
+1; this is The Right Thing.
> * Release an interim release right away to respond to this supposed
> "outcry" for a release. I've been opposed to this all along because I
> don't the quality of something released just to get folks to shut up
> will be all that high. A snapshot with an "official" number will
> likely do more harm than good.
-0; this is silly and wastes time, but isn't as actively harmful as ...
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an "optional" part. If it's done, awesome; if not,
> include it in the next release. The current admin has some bugs, yes,
> but it's usable enough. As long as we advertised that it's on the way
> out we shouldn't have too much trouble.
-1. Releasing 1.0 with a major feature's implementation already
depreciated seems like The Wrong Thing, no matter what project we're
talking about. Echoing others: once we're past 1.0, this sort of
aggressive timeline would be fine for minor releases.
> Speaking of sprints, are there any plans to hold a Django sprint
> during Europython 2008 (only one month away now)?
I added Django to the Sprint Suggestions page in the Europython wiki
[1] some time ago and remember Jacob agreeing that it's a good idea.
The sprint days are "from Thursday 10th July until Saturday 12th July
(three whole days)".
Although I'm sure there are a lot people willing to work remotely I
wonder if there are other people coming to Europython?
Cheers,
Jannis/jezdez
You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I
> Lack of visibility on what is going on with 1.0 and over an year delay
> on 1.0 (perceived) is causing people to get frustated and we see these
> discussions threads every few weeks now.
I'm really, honestly baffled by this statement. Django development
happens in the open. Always has. Anyone anywhere at any time can look
at what's going on, see what the dev team is talking about, etc. And
it's not like the places where the discussion happen are a super top
secret; a link to the dev list is publicly advertised on
djangoproject.com, as is the bug tracker and wiki.
So please, in all honesty, tell me why you think Django's development
process isn't "visible" enough for people who are concerned and want
to get information. If there's a genuine issue I'm missing here, I'd
love to correct it.
> So please, in all honesty, tell me why you think Django's development
> process isn't "visible" enough for people who are concerned and want
> to get information.
I give you example: few weeks ago I discovered that problem #3030
still persists: somebody fixed it by introducing
DatabaseFeatures.autoindexes_primary_keys, but left its value in the
backend.mysql.base to be False, hence the fix has no effect...
If I was asking why, there is no answer, so I don't know what
development process is behind, whether:
- everybody just fucks me off
- nobody cares about MySQL
- nobody knows
- it is an intention
- it is easiness
- will anobody fix it
- should I fix it
- etc...
###
And there is more examples...
###
Concerning the original topic: asking for frequent releases, it is
IMHO similiar as with those 'checkbox features' mentioned by Joel
Spolsky http://www.joelonsoftware.com/articles/fog0000000339.html
Peter
Er. You linked to a well-known thread in which the plan for 1.0 was
published; do you mean to say that this is evidence that there is no
publicly-available plan for 1.0 (which is self-contradictory), or have
I disastrously missed something?
I think it depends on the project, but I wouldn't mind hearing more of
your thoughts on this because it's something I have to deal with.
Perhaps we should take it offline unless others might benefit from the
conversation.
When our projects are done, they're done. They work as intended and I
don't see any reason to upgrade them from 0.96 to 1.0. If it ain't
broke, why fix it? When 1.0 comes out, we'll upgrade our core
libraries to work against 1.0 and that will be our new default. The
only reasons I can think of to want to upgrade a finished site is for
security or major performance enhancements -- one of which is usually
back-ported to 0.96 for as long as it's supported (which I'm not sure
Django has specified). What I'm wishing for in trunk are more
developer friendly features -- things that make it easier on the
developers.
Please tell me more about the legacy problem you are predicting.
And for Django devs -- are there specific dates or number of releases
when Django no longer rolls out security patches for older releases?
Thanks,
Rob
Ah, that's a foreign concept to me. In that case, yeah, your strategy
sounds good. :)
...
> Please tell me more about the legacy problem you are predicting.
>
Our projects are never done; the codebase is living. We have a
rolling migration problem, and our codebase is ever expanding. We try
to keep at a recent (but not tip) rev at all times.
> And for Django devs -- are there specific dates or number of releases
> when Django no longer rolls out security patches for older releases?
>
I believe it's one official release back. James will know better.
For security we patch trunk, of course, as well as current stable
release plus the two previous releases. This means we currently
provide security updates for trunk, 0.96, 0.95 and 0.91.
As an aside, we have a number of clients running on checkouts of the
SVN "bugfixes" branches for their versions of Django, which makes
management of that sort of thing quite easy -- security updates are
just an 'svn up' away for them, and for stuff we host it actually
reduces down to a single Capistrano task to deploy that :)
Just a note up front, Django has completely changed the way I build
websites and I'm totally enamored with it, but I'm trying to think of
how official releases could have benefitted myself in my situation and
this is what I came up with...
Let's pretend the following history occurred...
* 0.97 was released with the major change being the update to unicode.
* 0.98 was released whose main features were auto escaping and QSRF.
* 0.99 will soon be released whose main feature is newforms admin.
* 1.0 will be released with minor updates and stabilization.
Some benefits I see if this had happened. Specific pretend version
examples reference those above...
* Easier to know up front what's new, backwards incompatible, etc.
because there'd be release notes and we can plan to migrate when
ready. Versus an arbitrary revision and checking the backwards
incompat wiki page, looking at docs to see what has "New in
Development Version", etc.
* Easier to set up a server to host Django apps depending on all of
0.96, 0.97, 0.98 vs possibly having revs -- at least you can simply
svn up a point release branch for security fixes. On revs you'd have
to back port a patch to a certain rev if a security fix was released
to not also update the stuff you don't want. Another example is
Webfaction -- they now offer 0.96 and "trunk", but who's trunk is it
and when is it updated? I don't want my website to break b/c they
updated out from underneath me. I'd much rather have a recent point
release that I can depend on and still get some of the new goodies in
recent Django.
* Online HTML documentation is frozen with each release. If we were
tracking individual revs, this is not true -- docs would only be
frozen with the Django tree. This also gathers people around a
vocabulary, e.g., you can ask which version a person is using more
definitively. If a person says "trunk" you have to know which
revision or when they last updated. If they say, "I updated to 0.98
and now I see HTML garbage in my website." you know it's probably
because of the auto escaping.
* 3rd party apps could more easily plan updates. For example, after
qsrf merge, django-tagging was broken. If django-tagging instead said
it worked against 0.97, there could have been a planned update to
0.98. Granted, the breakage would have still occurred for those
following trunk, but the benefits of the releases above is that the
3rd party people can claim with certainty that their code works
against a certain release, not "this works against trunk and may break
if they change their API."
* There have been a few cases where getting something in trunk to get
more eyes on the code to work on it has been beneficial. After a
point release you can merge in unstable code and get the main
developer's eyeballs fixing things (sort of like the flurry of code
coming into the Linux kernel after an official release). It sounds
like a faster iteration process to me than people not wanting to break
trunk b/c it's the norm to run production websites off of it.
I'm not arguing for the above releases or a pre 1.0 release, I'm only
trying to make some claims that frequent releases can be a good thing
for the Django ecosystem as a whole.
-Rob
Rob, let me step back a moment and point out how this comment would
strike me if I didn't know you and didn't know that it wasn't your
inention to come off this way.
The way you've laid this out would sound as if you think that:
A) The Django dev team is unaware of these arguments, or
B) The dev team is aware of them but is willfully ignoring them.
Of course, that's not how you meant it to sound, and neither one of
those things is true, but please do keep in mind that it's one possible
reading of your statement.
Meanwhile, the thing that I, personally, feel keeps getting overlooked
is the fact that what we're really talking about here is a trade-off:
doing multiple interim pre-1.0 releases would have had advantages,
yes, but it also would have had disadvantages. For example:
* The time the dev team devotes to Django would be stretched even
further by needing to do multiple rounds of QA and support for these
releases.
* Downstream distributors would similarly face an increased workload
for these releases.
* End users would face a series of major backwards-incompatible
releases over a relatively short period of time. And this one is
really the killer, because instead of having a "here's the stable
pre-1.0 release, you can pin to it until you're ready for the jump"
policy, we'd have that release -- and the one after it -- falling
off the support policy (three releases plus trunk is tricky enough;
six releases plus trunk would be a nightmare. As a result, 0.96 and
a hypothetical 0.97 would have to lose support) and forcing upgrades
on people who didn't necessarily want them.
There would be frustration from people who want to stick to, say, the
hypothetical 0.98 but need a third-party app that forges ahead to the
hypothetical 0.99. There would be gnashing of teeth from people who
would hear that they need to upgrade and do all the QA and work to get
on a new, incompatible release, only to have to do it again in a couple
months because the third-party stuff won't stand still for them.
This last paragraph should sound familiar, by the way, because it's
really not any different from the situation of someone who wants to,
say, work on a post-autoescape but pre-qsrf Django right now.
Similarly, people would complain about having to accept
backwards-incompatible changes and further rounds of QA and upgrading
as a side effect of picking up new features or third-party
compatiblity with each release. And again, this is no different from
what people complaing about right now with trunk.
Which brings this back to being a trade-off. The decision that's been
made does incur one set of downsides, yes, but it avoids
another set. And it introduces a certain simplicity to deployment
choices:
* If your primary concern is stability and compatibility rather than
features, 0.96 is stable and supported and you should use it.
* If you're more interested in getting access to new features, and
for your project's needs that outweights the cost of wading into a
moving target, you can snapshot trunk and run off that.
And when 1.0 lands, both groups have a clear, single-step upgrade
process to get onto the final 1.0 codebase.
I think that's the better plan by far, and that's why I thought and
still think that we should stick to it: of the available trade-offs we
can make, I think this is the one that results in the least amount of
wailing and gnashing of teeth on the part of everyone involved.
Jacob,
I definitely understand the frustration at passive aggressive lashing
out. However, I've worked in organizations where passive aggressive
behavior was the norm, and ones where communication was clear and open,
and in ones where it wasn't. In every single case, this had to do with
how management responds to complaints. If people feel that their issues
are being responded to, gripes are aired openly, and if they don't,
there's a lot of quiet, unproductive grumbling. Without exception.
In this case, I would specifically point to things like this:
"I'm pretty sure its been stated several times on the board but there
will be no versions released between .96 and 1.0."
I don't mean to pick on one person in particular, as this has been a
pretty common tone of response to questions about the possibility of
a .97 release.
The entire point of the blog post was that this stated policy is
problematic (agree or disagree as you like), so simply stating again
that it's not going to happen without addressing the points in the
complaint is not going to make the person feel like their complaints
have been heard, so they'll take them elsewhere.
On an open source project, it's a little more complicated because it's
not always clear to everyone involved who the core developers are, but
if nobody steps in to disagree with statements like the one above, or to
clarify it with direct reference to the specific complaints it will
start to sound like the consensus of the django community.
The rest of your response (which I haven't quoted here--sorry) does
address the blogger's concerns, and is exactly how good management can
work to reduce passive aggressiveness. Kudos for it. You don't have to
do what the complainant is asking you to do, but at least make it clear
that it's being looked at.
I'm also on the fence about whether posting a blog about it is really
passive aggressive behavior. On the one hand, you're right that
django-dev is the one place where something might actually be done about
it. On the other hand, it brings people into the conversation who
aren't regulars on django-dev, which is great for getting around the
myopia that affects all groups. The conversation that took place in the
blog comments is very different from the one that's taking place here,
and not in entirely bad ways. Furthermore, imagine if the only place to
find conversation about, for example, design decisions in python were on
the python dev list. How would someone thinking about learning a new
language be able to evaluate if python were good for their needs? The
conversation that would take place on python-dev would be above their
heads, but it would still be useful information for them to have.
Surely the mailing list shouldn't be the only location for discussion
about django's great features or its faults. I don't think we'd want to
discourage people from discussing django openly on their blogs. That's
publicity.
I don't think complaining about passive-aggressive behavior will
actually discourage passive-aggressive behavior. Develop a reputation
for being responsive to user concerns (again, this doesn't mean doing
everything they ask), and the passive aggressiveness will go away.
For the record, I would vote in favor of intermediate releases primarily
because of security patches. Where I work, projects are grant funded,
which means when they're done, there is nobody who is paid to maintain
the site. They have to stand alone. If we have an older version of
trunk, we can't SVN up to get the security patch, because there's nobody
to fix backwards incompatibilities. If there's a problem with
obsoleting older versions too quickly, maybe the obsolescence policy
should be looked at (base it on time rather than version number maybe,
but that's another conversation).
Cheers,
Cliff
I agree with the sentiment of this, but we've passed the point where
it's a useful argument.
* A year and a half (with still a major branch to be committed before
1.0 lands and no release date in sight) is *not* too frequently to have
a couple incompatible updates. The longer the stretch before 1.0, the
less true this argument becomes.
* Further nobody is going to be forced to update just because it has a
number on it any more than they're forced to keep up with trunk. In
fact, there will be less pressure to update, because security patches
will be backported.
* The only exception is, as you mention people who are relying on third
party apps, but this doesn't hold water either, because many third party
apps are actually based on trunk (or worse! branches of trunk).
I do see from Adrian's post above that there is some rethinking of the
release schedule going on now. As you said, there's a trade-off to be
had with releasing now and holding off to 1.0, but as the interval
stretches out, the balance shifts toward the need to release, and maybe
we've reached the threshold where the problems with the current release
plan are starting to outweigh the benefits. We'll see.
Cheers,
Cliff
I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gain over
finishing 1.0 ;)
> * A year and a half (with still a major branch to be committed before
> 1.0 lands and no release date in sight) is *not* too frequently to have
> a couple incompatible updates. The longer the stretch before 1.0, the
> less true this argument becomes.
People have been saying that they'd like to see, for example, a
six-month release schedule. That's about the shortest that's
practicable in terms of expecting people to go through the upgrade
process. But since this time last year, I count the equivalent of four
major breaking (in the sense of either "loses backwards compatibility,
or otherwise requires significant effort to port across) changes and a
fifth is on the way. Assuming, as I hope it will, the newforms-admin
is done within the next couple of months, that's equivalent to a
"release cycle" of 2-3 months with a non-trivial upgrade process along
the way.
So following several folks' suggestion of releasing every time a big
breaker lands would have pushed us through 0.97, 0.98, 0.99 and
probably two more *pre-1.0* non-trivial upgrade processes in just over
a year. I don't see that as a smart thing to do.
> * Further nobody is going to be forced to update just because it has a
> number on it any more than they're forced to keep up with trunk.
In a "release early, release often" scheme, yes they will, because --
as I've pointed out already -- such a scheme would push at least two
releases over the support cliff. Plus, third-party apps would likely
track the latest stable release on a faster schedule, which means that
there would be no alleviation of the "I'm on Django xxxx and the app I
want to use is on Django yyyy" problem people have complained about.
> In
> fact, there will be less pressure to update, because security patches
> will be backported.
Nope. At the very least, 0.96 and a hypothetical 0.97 would lose
support before 1.0, and potentially (depending on how aggressive a
hypothetical release schedule you want) a hypothetical 0.98 would lose
support too. And no support == time to upgrade.
> * The only exception is, as you mention people who are relying on third
> party apps, but this doesn't hold water either, because many third party
> apps are actually based on trunk (or worse! branches of trunk).
My point about third-party apps is simply to note that more frequent
releases would not alleviate versioning issues with third-party apps.
"My codebase and apps are written for pre-autoescape trunk but this
third-party app I need is written for post-qsrf trunk" is
fundamentally no different from "my codebase and apps are written for
Django 0.97, but this third-party app I need is written for Django
0.99". In other words, more frequent releases do not solve this
problem (unless of course, we're talking about 1.x releases where
compatibility within the line would be maintained).
> I do see from Adrian's post above that there is some rethinking of the
> release schedule going on now.
If so, I missed it; I don't see anything from Adrian in this thread.
> As you said, there's a trade-off to be
> had with releasing now and holding off to 1.0, but as the interval
> stretches out, the balance shifts toward the need to release, and maybe
> we've reached the threshold where the problems with the current release
> plan are starting to outweigh the benefits.
At this point, I don't see any possible gain to be had. With one
large-scale item left to land on the 1.0 checklist (everything else is
smaller and/or more distributed in terms of workload and/or doesn't
involve breaking changes) and with development ramping up on that item
(newforms-admin) to get it done, I don't see how an interim release
would be anything other than a slap in users' faces: "OK, you begged
for a release before 1.0, so here it is, so close to the time of 1.0
that it's practically pointless."
I'm willing to be convinced, but it depends on how far out that release
is. As of now there's no release date.
You've said that the pain of upgrading is too great if we're just going
to supercede it in a few months. So if you are confident that we're not
much more than three months from being in 1.0 pre-releases, then I'll
keep quiet, and see what I can do to help out with getting features
landed. On the other hand, if our current status is "Maybe Three
Months, Maybe Nine Months," it might be worth the risk of an interim
release.
Cheers,
Cliff
On Mon, 2008-06-09 at 15:28 -0500, James Bennett wrote:
> On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <j...@sdf.lonestar.org> wrote:
> > I agree with the sentiment of this, but we've passed the point where
> > it's a useful argument.
>
> I'll concede that if you'll concede that we've also passed the point
> where issuing interim pre-1.0 releases offers any real gain over
> finishing 1.0 ;)
>
> > * A year and a half (with still a major branch to be committed before
> > 1.0 lands and no release date in sight) is *not* too frequently to have
> > a couple incompatible updates. The longer the stretch before 1.0, the
> > less true this argument becomes.
>
> People have been saying that they'd like to see, for example, a
> six-month release schedule. That's about the shortest that's
> practicable in terms of expecting people to go through the upgrade
> process. But since this time last year, I count the equivalent of four
> major breaking (in the sense of either "loses backwards compatibility,
> or otherwise requires significant effort to port across) changes and a
> fifth is on the way. Assuming, as I hope it will, the newforms-admin
> is done within the next couple of months, that's equivalent to a
> "release cycle" of 2-3 months with a non-trivial upgrade process along
> the way.
As mentioned in my previous post, if it's indeed three months, I agree,
but if it's only "hopefully" three months, then do we want to end up six
or nine months out still waiting for 1.0 to land "in a couple months?"
The tension seems to be, how hard to we push for 1.0, especially as
regards NFA? Are there only two options? To release 1.0 on a firm
deadline regardless of the state of NFA or to hold off until NFA is
released regardless of how long that takes?
Both options have risks. Maybe balance the risks by shooting for (e.g.)
two months, with a firm deadline of releasing 1.0 regardless if another
five months pass without NFA. Just a thought. Both 1.0 without NFA and
no 1.0 for a year sound pretty horrifying to me.
>
> So following several folks' suggestion of releasing every time a big
> breaker lands would have pushed us through 0.97, 0.98, 0.99 and
> probably two more *pre-1.0* non-trivial upgrade processes in just over
> a year. I don't see that as a smart thing to do.
>
Agreed. But that suggestion is not the only alternative; a six month
compromise would not have been out of the question. (of course
hindsight is 20/20 and all, but lets take that hindsight and look
forward).
> > * Further nobody is going to be forced to update just because it has a
> > number on it any more than they're forced to keep up with trunk.
>
> In a "release early, release often" scheme, yes they will, because --
> as I've pointed out already -- such a scheme would push at least two
> releases over the support cliff. Plus, third-party apps would likely
> track the latest stable release on a faster schedule, which means that
> there would be no alleviation of the "I'm on Django xxxx and the app I
> want to use is on Django yyyy" problem people have complained about.
>
> > In
> > fact, there will be less pressure to update, because security patches
> > will be backported.
>
> Nope. At the very least, 0.96 and a hypothetical 0.97 would lose
> support before 1.0, and potentially (depending on how aggressive a
> hypothetical release schedule you want) a hypothetical 0.98 would lose
> support too. And no support == time to upgrade.
>
Maybe that policy should be looked at? Obviously there are limited
resources for maintaining security patches, but it would be easier to
organize a grassroots effort for the community to support backporting
security patches to a hypothetically-obsolete older release or two, and
sharing it with the community than it would be to ask everyone running
an older trunk to create backport their own patches.
> > * The only exception is, as you mention people who are relying on third
> > party apps, but this doesn't hold water either, because many third party
> > apps are actually based on trunk (or worse! branches of trunk).
>
> My point about third-party apps is simply to note that more frequent
> releases would not alleviate versioning issues with third-party apps.
> "My codebase and apps are written for pre-autoescape trunk but this
> third-party app I need is written for post-qsrf trunk" is
> fundamentally no different from "my codebase and apps are written for
> Django 0.97, but this third-party app I need is written for Django
> 0.99". In other words, more frequent releases do not solve this
> problem (unless of course, we're talking about 1.x releases where
> compatibility within the line would be maintained).
>
Agreed, except that there are fewer targets. My point was that frequent
releases are not *causing* this problem. The problem already exists.
> > I do see from Adrian's post above that there is some rethinking of the
> > release schedule going on now.
>
> If so, I missed it; I don't see anything from Adrian in this thread.
>
Heh. My mistake. It was Jacob. Proposing "train releases."
> > As you said, there's a trade-off to be
> > had with releasing now and holding off to 1.0, but as the interval
> > stretches out, the balance shifts toward the need to release, and maybe
> > we've reached the threshold where the problems with the current release
> > plan are starting to outweigh the benefits.
>
> At this point, I don't see any possible gain to be had. With one
> large-scale item left to land on the 1.0 checklist (everything else is
> smaller and/or more distributed in terms of workload and/or doesn't
> involve breaking changes) and with development ramping up on that item
> (newforms-admin) to get it done, I don't see how an interim release
> would be anything other than a slap in users' faces: "OK, you begged
> for a release before 1.0, so here it is, so close to the time of 1.0
> that it's practically pointless."
>
Again, I'll buy that argument if we can really push 1.0 in the short
term. My concern is that this has been one of the arguments for
avoiding 0.97 before. Of course the closer we get to release, the truer
it gets, but also the more evident it becomes that it wasn't *really*
true before (when we were still 12 months away from 1.0, for example).
I'll start poking my nose into NFA to see what I can do to help.
Cheers,
Cliff
On Mon, Jun 9, 2008 at 1:35 PM, J. Cliff Dyer <j...@sdf.lonestar.org> wrote:
>
>
> On Mon, 2008-06-09 at 15:28 -0500, James Bennett wrote:
>> On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <j...@sdf.lonestar.org>
>> wrote:
>> > I agree with the sentiment of this, but we've passed the point where
>> > it's a useful argument.
>>
>> I'll concede that if you'll concede that we've also passed the point
>> where issuing interim pre-1.0 releases offers any real gain over
>> finishing 1.0 ;)
>>
>
> I'm willing to be convinced, but it depends on how far out that release
> is. As of now there's no release date.
>
It seems to me this conversations is drifting toward the all or none
approach -- wait until 1.0 lands vs. six month/incremental releases.
Can we not consider a middle ground? If new-forms-admin is 6 months
or a year from landing, then why not a single release now to get a
more current release out? I know there is some feeling that a release
just adds work at this point with little benefit, but I could see the
point of a single release to catch recent big changes and allow Django
users to upgrade in a couple steps rather than large backwards
compatible break that 1.0 is likely to be.
As I said earlier, I can go either way on this discussion. I see
valid points from all the arguments. I fully support James, Jacob, et
al on wanting to wait until 1.0, but at the same time, what's the harm
in a single release until then? Not just to quiet the nay-sayers, but
many, many people just don't notice the activity going on in Django
without a release to call attention to it.
Cheers,
deryck
--
Deryck Hodge
http://www.devurandom.org/
Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.
Adrian
Because autoindexes_primary_keys was added to support Oracle, not for
ticket #3030. I don't think we were really aware of the ticket at the
time. Where we didn't know the correct value, we left it as False to
preserve the prior behaviour, which we presumed to be correct. MySQL
is an especially complicated case due to the large differences between
multiple supported versions.
I don't know why this is so mysterious. A small amount of browsing
turns up that the code was added in revision [4916] and specifically
enabled for Oracle only to fix ticket #3743.
> If I was asking why, there is no answer, so I don't know what
> development process is behind, whether:
I for one did not see the question.
* Start a "train release" schedule: schedule a couple of 1.0 betas, a
rc or two, and then a final release. Features that are done by the
dates get released, those that aren't, don't. Make these dates
aggressive but not crazy. And -- here's the controversial part -- make
newforms-admin an "optional" part. If it's done, awesome; if not,
include it in the next release. The current admin has some bugs, yes,
but it's usable enough. As long as we advertised that it's on the way
out we shouldn't have too much trouble.
Thoughts?
> I'd trade your controversial part for an alternative: merge mewforms-
> admin back to trunk now. It's been as 'usable' as old admin for
> months. Sure, it's got a couple of dozen 'blocking' bugs in the
> tracker but none of them are all that serious. Current admin, as
> you note, also has some bugs. Trade the existing known-never-going-
> to-be-fixed current admin bugs for a different set of newforms-admin
> bugs and get on with fixing the second set already. Once on trunk
> the community's interest will be higher so you'll get better
> feedback on what is and is not really important to users, more
> people who might help out with actual fixes, etc.
Hear hear, I'm definitely +1 on this, for exactly Karen's reasons. I
spend a lot of time tinkering on trunk, but I don't usually have
enough time where I could easily track on two separate branches. When
a problem hits me in the face, I work on it, I don't go looking for
new ones...well, most of the time. :)
George
+1
I know there is a commitment to keep trunk as stable as possible, but if
there is a push for moving forward quickly, this is the way to go. I'm
running newforms-admin for several public sites already, and have not
experienced a single problem which I'd remember now. Porting from the
current admin to nfa was very straightforward too.
+1
+1
We have a production-based web application running nsf for the past 4
months with no show-stoppers. (Small occasional bugs that already have
tickets, patches.)
-Alen
>
>
> >
>
I'd trade your controversial part for an alternative: merge mewforms-admin back to trunk now. It's been as 'usable' as old admin for months. Sure, it's got a couple of dozen 'blocking' bugs in the tracker but none of them are all that serious. Current admin, as you note, also has some bugs. Trade the existing known-never-going-to-be-fixed current admin bugs for a different set of newforms-admin bugs and get on with fixing the second set already. Once on trunk the community's interest will be higher so you'll get better feedback on what is and is not really important to users, more people who might help out with actual fixes, etc.
so model-level validation will be dropped from 1.0?
gabor
+1 as soon as it's deemed that NFA has surpassed oldforms -- as
measured by bug-free-ness, flexibility of the admin, and general
consensus of the core developers -- I think merging it into trunk
will
1) increase visibility by the less-adventurous (read "only as
adventurous as trunk, not a branch") developers
2) move a step towards Jacob's "let's get on a train" suggestion
3) appease the "we want a 1.0" crowd with notable progress
towards a 1.0
I'd also add that a public announcement like was done for QSRF
would help keep it well in the open, rather than a one-line "oh,
we merged NFA into trunk" added to the backwards-incompat page.
That way, like with QSRF, folks know there will be a shake-down
period where a higher volume of bugs will be found/filed and they
can prepare/test accordingly.
It might also help to have a clear catalog of "1.0 blocking bugs"
that would prevent a 1.0 release (there might be something in
Trac that gives this, but my poking didn't find it) so the "we
want a release" crowd has a tangible list they can be helping with :)
Just my $0.01
-tim
+1 if involved people in this branch agree (I hadn't found the time to
test it yet...).
> I think it's a shame newforms-admin wasn't done in a fashion similar
> to newforms
Very good idea, the transition/merge will be easier if there is an
alternative like that.
David
So here's the deal. The core developers have always had a vague idea
about what would be in 1.0 and when it would be released, but it's
apparent we've not been formal enough about that plan. To wit, many
folks are complaining about a lack of a feature list for 1.0 even
though there's been one on the wiki for quite some time. Seems wikis
still don't inspire all that must trust -- sorry Jimmy.
I've been talking over the past few days with other core developers,
large-scale users of Django, and, well, anyone else I find on
#django-dev. I'm readying a proposal that I think should make most
people happy (or, at least, content). It's not quite done, and I'm
busy today, so plan to see it tomorrow.
Jacob
> I'm not certain that this route is perfect, but it seems to be a
> compromise of both worlds.
We use the same approach with mean time redundancy about 1 months.
Peter
I love the smell of troll in the morning, don't you?
> On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson
> <trebor...@gmail.com> wrote:
>> I think the most often reason why I've heard is that it takes time to
>> create a release, post it, push security patches to it, etc. Which
>> makes sense, but at the same time there are a lot of valid points in
>> the blog post.
>
> It does indeed take time to roll a release. More importantly, issuing a
> release means that we -- the Django team -- make a promise of support
> for it, which is the important part and the part that ultimately ends up
> eating much more time. It's also the part people tend to forget about
> when they start asking why we don't just roll a new release whenever
> they think we should.
>
> We've stated in the past that the next official supported release of
> Django will be 1.0. I think that's a good idea, and I personally think
> we ought to stick to it; the things we've outlined for 1.0 are
> significant enough that incrementally pushing releases before that will
> do more harm (in terms of presenting a constantly-moving target to the
> people who believe releases mean long-term stability) than good.
>
> And, really, that's the catch-22: if we released much more frequently
> than we do now we'd likely get just as many complaints, only from a
> different group of folks. As has been stated before, having people
> upgrade from 0.96 to a 0.97 release based on current trunk would subject
> those people to a fair number of required changes; having them upgrade
> at each step along the way to 1.0 would impose that on them repeatedly.
> That's not something I'd be comfortable with; I'd rather try to minimize
> the number of releases which involve significant end-user changes. The
> ideal is to just do it once, and then we're at 1.0 with a compatibility
> guarantee toward the future.
>
> So personally, I think discussion of more aggressive release schedules
> should happen once we're *at* 1.0, with a hard promise of stability.
> Once we're there, more frequent releases (say, to add new features or to
> expand django.contrib) make a whole lot more sense to me. But right now
> as we're working through the changes necessary to reach 1.0, I don't see
> much good in diverting that goal to produce interim packages that will,
> in turn, increase our support workload.
+1 on including NFA in 1.0 release (even if it has a few bugs). Stick to
what you presented in the list of 1.0 features and get it done. Imagine
people spending weeks porting their code to an interim release only to
have to go through another substantial code change just because of NFA.
I've been tracking trunk, so my changes won't be as huge, but for some
people, it will be massive, and I think they would all prefer to do it
once, no matter what they say now.
I think having a date everyone could look forward to would:
a) get everyone busy planning and preparing for it instead of venting
their frustrations.
b) help developers get it out the door.
Well, nfa is doing pretty well; as others have mentioned, it's at or
near parity (functionality-wise) with the current admin, and
incidentally has already fixed quite a lot of bugs which hamper the
current admin. So even a pessimistic estimate would have to concede
that it's quite close, and it's the last huge change to land before
1.0, which in turn means that by the time we'd get back to normal
development after doing QA and everything for an interim release, we
could instead be doing 1.0 alphas or betas.
(and note that I'm not relying on any secret insider information in
saying this, because there isn't any; I just pay attention to what's
going on publicly)
> Maybe that policy should be looked at? Obviously there are limited
> resources for maintaining security patches, but it would be easier to
> organize a grassroots effort for the community to support backporting
> security patches to a hypothetically-obsolete older release or two, and
> sharing it with the community than it would be to ask everyone running
> an older trunk to create backport their own patches.
I personally wouldn't have any problem with keeping a branch or two
alive and giving a couple trusted community folks commit bits on it if
they want to maintain support past the official period for a release.
But like all things, that would take time to get going, and since I've
already pointed out that on a "release when a big thing finishes"
schedule we'd probably be kicking out releases far too quickly for any
such effort to keep up (having to hunt up new community maintainers
every couple months probably wouldn't have worked).
> Agreed, except that there are fewer targets. My point was that frequent
> releases are not *causing* this problem. The problem already exists.
Not really, no; there'd be just as many targets, only they'd have
different names ("Django 0.98" instead of "QSRF merge", for example).
> Again, I'll buy that argument if we can really push 1.0 in the short
> term. My concern is that this has been one of the arguments for
> avoiding 0.97 before. Of course the closer we get to release, the truer
> it gets, but also the more evident it becomes that it wasn't *really*
> true before (when we were still 12 months away from 1.0, for example).
Keep in mind that, twelve months ago, 0.96 wasn't even six months old.
At any rate, Jacob's already mentioned he'll be posting quite a lot of
information quite soon; it'll largely just be collating a lot of
already-available information into one document and slapping some
projected dates on it, but perhaps that'll help a bit.
It's apparent from the recent blog and list activity that some members of the
Django community feel that we've screwed up in waiting so long to make another
release; some have started to despair that we'll ever ship 1.0. This uncertainty
has been confounded by our failure to be more transparent and open about the
roadmap for 1.0. Though the core developers all have a good picture of what
should be done before 1.0, I've done a lousy job communicating that and asking
for feedback. Further, it's clear that not having a definite timeline has really
pissed some people off.
This lapse of communication and lack of a timeline is primary *my* fault, and to
anyone annoyed, angered, or inconvenienced, and to the community in general,
I apologize.
I appreciate all the constructive criticism. Please, if you feel strongly about
this -- as I know many do -- come participate! I've just posted a draft 1.0
timeline.
Jacob