On Sat, Nov 29, 2003 at 10:38:20AM +0100, Jostein Chr. Andersen wrote:
> I'm really sorry: -No! I (and I sure hope others) consider that
> "/tags/0.34.0/" have a codefreeze (it's done a week before release for a
> very good reason).
> I have no problem at all to understand that it's very easy to be tempted
> to merge stuff into the release branch, the branch just are there, ready
> to be improved. But I say no, improvements are for upcoming versions.
>
> Only changes related to the new version as CHANGES, svn_version.h and
> other stuff that's related for making a good subversion-X.YY.Z release
> out of a given revision should be done.
>
> An exception from this rule is strongly needed fixes, such as: -The
> repository will be destroyed and the cat will be put on fire if we don't
> merge that change.
> So, sometimes, merging from a revision have to be done in order to make
> the release run at all.
>
> I know that Chia-liang is eager to have r7861 merged into the release
> branch to (and I'm a Perl fanatic and would love to have it on 0.34.0),
> but won't do that either without approvement from Subversion's
> "masters".
>
> So my policy about this is that even changes that probably don't affect
> stability at all won't make it before next release.
>
> Of course, this might be discussed and I can change my mind - in fact, I
> have to if "everyone" says I should or else..
I'll admit I haven't been around much so my opinion probably doesn't
carry much weight. And perhaps my limited observations are wrong about
the way things work.
Most projects tend to do a code freeze for new features, fix any
outstanding bugs, and then do a release. Granted subversion is in a
different place in it's life than most projects that do things like
that. subversion is simply and flat out a developing project. So it's
impossible to fix every bug before a release.
As it seems to me the release procedures are rather haphazard and
unclear. It is clear how to make the tarball, but it's unclear how the
branch is to be handled and what changes qualify as "absoluetely
necessary."
If you follow the notes/releases.txt the CHANGES file, svn_version.h etc
should have been done before the branch was made.
Perhaps the following change would eleviate this, give everyone a clear
picture of what goes in, and hopefully result in better releases:
* Releases are branched a week before they happen.
* Bugs may be fixed, features may *NOT* be added, significant code
changes should be avoided unless absolutely necessary (meaning core
functionality won't work without it).
* After a few days (3 or 4) close the branch to bug fixes unless core
functionality is broken. At the end of the week, release happens.
Under a structure like this, I'd say that the fixes to the java thing
should happen. And that the perl changes shouldn't...
On an unrelated issue. Someone should really add a requirement to do a
make clean to the tar ball build procedures. On the last two .1
releases I've had trouble with the .info file(s) still existing so they
don't get built fresh. Doing a make clean fixed the issue but that
shouldn't be necessary on a freshly extracted tar ball..
Anyway this is just my two cents.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 29 11:45:23 2003