On Mon, 2007-10-01 at 12:18 -0700, Joe wrote: [...] > Are you sure there is no compromise on doing a "stable" tag every few > months? Unless you religiously monitor the timelines and the google > groups, it is a little difficult to pick a good time to tag the trunk > between major merges and refactors.
Look, I agree and can sympathise with this. I don't know of a perfect solution here -- and I've been involved in similar release discussions in other projects, trying to work out how to help distributors (Red Hat, Suse, Mandriva, etc) stay in sync. In the end, they really have to either pick a released version or -- in the periods between releases -- take a snapshot and work with that. The hard part about sticking a less formal "stable" tag on something is working out what it means and when would be the right moment to do so. As a practical issue, at almost any given moment in time (certainly more often than not), a random snapshot is going to be relatively bug free. We really are serious about keeping the tree running as perfectly as possible at any given moment and if somebody checks in something that breaks the tree in a big way, it has an expected lifetime measured in hours, not days. So how do we pick one moment as being more stable than another and worthy of a tag? Flipping that around and saying that we could therefore pick any moment to tag just to satisfy the corporate arena is one of the things that doesn't usually happen in open source projects. If your constraints are such that running against a snapshot is not approved, then playing word games to pretend something isn't a snapshot (whether we play the games or you do with an internal snapshot) is the sort of futile approach that only leads to disillusionment when whoever is in charge of policies find out they've been had. There are a lot of us running Django trunk in production environments. However, as the original poster in this thread discovered, many uses are also going to require patches against trunk in certain circumstances -- so things aren't "stable for all uses". Most of the popular trunk modifications that people are making are on the table for resolution in one form or another prior to 1.0 -- and that is one of the triggers for when we will be ready to release. So right this minute is no more or less stable than last week or next week. However, it's also quite a way away from where will be at 1.0, so it's not really stable in the sense of "unmoving". The other slight concern here is that it's kind of solving a non-problem to a certain extent (and I say that realising this whole thread is revolving around that very contention and varying interpretations of it)... The original open sourcing of the Django subversion tree was in July, 2005. Django 0.90, the first release was in November, 2005 and 0.91 was December 2005. They were very early "make an initial tarball" releases. 0.95 was the post-magic-removal release (a major stability point after a period of instability and change) release in July 29, 200., 0.96 was March 23, 2007 and was motivated by being a stability point prior to a large number of changes leading up to 1.0. So we're churning out releases (very) approximately every eight months after getting the first tarballs out there, although that's actually driven by being "stabile point-in-time based". That schedule would mean that if we released 1.0 at the end of this year, it would be about the same gap. > I know there are concerns about this (end of life on releases, or > security fixes on releases, etc.). I am not really sure how this can > (if this can) be accomplished, but I think it would really help us > "corporate middle managers" out! > > Maybe you can tag "Release Candidates" with no guarantee of bug fixes? The problem I would see here is that marking something as a "release candidate" when it isn't leads to credibility problems for us down the track. You say you're trying to work through middle-manager problems in your organisation; we have the same issue with our community-at-large. If we start saying something is a release candidate when it's really miles away from that, when will they know which are the *real* release candidates. This might be solved by a change in terminology, but then you're back where you started with slapping a label on an essentially arbitrary snapshot, which you can do yourself. There seem to be two problems here: the practical one of when to take a snapshot (pretty much any time is as good as any other) and the paper one of what the label is on that snapshot and we're really can't do much more than make releases (and genuine release candidates as we'll do leading up to 1.0) when we think the right moment arrives. None of the above was the answers you were hoping to hear, I realise. I think you'll find that everybody who's bothered to participate in this thread is not unsympathetic to the problem, but putting an artificial stamp on something isn't the solution here. Either you can run code that isn't an official release -- without all the overhead we put into making sure a release is a good moment QA-wise -- or you can't. The middle ground of trying to create a blessed non-release that isn't just a snapshot doesn't really hold up. Best wishes, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
