Michael Price <mprice@atl.lmco.com> writes:
> Well, my impression of the first few commits was as follows:
>
> 1. Get the go ahead to bump the version number and commit CHANGES.
> 2. Copy HEAD to branches/0.18
> 3. Use dist.sh to create the tarball.
> 4. Fix bugs on branch.
> 5. Go back to step 3 as needed.
> 6. Merge relevant changes to trunk if needed.
> 7. Copy branches/0.18 to tags/0.18.
> 8. Remove branch if its no longer needed.
Yup! You've got the right idea.
Step 7 can just by 'svn mv', then you don't need step 8. We can
create a new branch later, if necessary.
Don't forget step 3.5: "test the heck out of that tarball" :-).
Regarding steps 4 and 6: now enters a bit of process-fu, which I hope
you won't find too inconvenient: one or more of the full committers
needs to review & approve changes that affect Subversion code (i.e.,
not just release administrivia like the CHANGES file and dist.sh).
Don't worry, review will come quickly, as people realize that this is
a release.
This is *not* because there's any reason to think you'd commit bogus
changes :-). It's just that you haven't yet been through the process
described in HACKING, whereby the committers see several patches from
you, someone proposes you for full commit access, etc, and release
management responsibility is orthogonal to that. (We try not to
burden development down with overmuch process overhead; on the other
hand, a little conservatism is appropriate when it comes to full
commit access.)
Note that someone may discover and fix a bug on trunk, which we
realize is in the branch too. In that case, steps 4 and 6 would be
"reversed": the bug is fixed on trunk, and gets ported out to the
release branch.
> So, when I'm running dist.sh, if I specify the branch (branches/0.18) as
> the REPOS-PATH then do I specify the VERSION from the commit in #1 above
> or do I use some other revision number?
That's a good question.
Ideally, we'd want to use the head revision number, to reflect the
head of the branch. But that could confuse people into thinking the
release includes head trunk changes, when it doesn't.
Since we'll always be releasing from branches from now on, I think
maybe we can change how dist.sh and version numbers work.
How does this policy sound:
subversion-0.18.0.tar.gz -- unpacks into subversion-0.18.0/,
always corresponds to tags/0.18.0/.
'svn --version' just prints "0.18.0",
doesn't include a revision number.
subversion-0.18.1.tar.gz -- unpacks into subversion-0.18.1/,
always corresponds to tags/0.18.1
'svn --version' just prints "0.18.1",
doesn't include a revision number.
And so on. Since these are branch releases now, it's time to lose the
revision number from the tarball name.
Meanwhile, for subversions built from a trunk working copy, we just
have 'svn --version' print out the revision number. That is, instead
of
svn, version 0.17.1 (dev build)
it will say
svn, dev build, revision 4960
or somesuch. This is possible now thanks to Philip's 'svnversion'
program, which see.
What do you think? This would mean that dist.sh, and possibly a few
other things, would need some tweaks, but it will make things a lot
clearer in the long run. Up for it?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 19 19:48:07 2003