Am Dienstag, 12. September 2006 02:30 schrieb Christian Ohm: > While looking at the wiki, I noticed the following page: > > http://wz.rootzilla.de/wiki/user:release_checklist > > This might be extended to some general SVN guidelines, like: > > "On every check-in: > - Check if your changes compile and run > - If you're not sure about other systems, add that to the log message > - Modify the ChangeLog according to your changes, if necessary Ideal case, but I know this will often be forgotten. So doing this in a regular interval seems to be safer to me currently. (I know which revisions are represented in the ChangeLog and which not just by looking at the log.)
> - Check in one change at a time
(Commit in logical units and compile-save units)
> - Check what you check in ("svn diff | diffstat", "svn diff")
> - Write a descriptive log message: For new features, describe how to
> use them, list possible problems
Or tell a wikipage / br where to find that info.
>
> For larger changes:
Very large changes. As we see on BerliOS we can have dozens of branches, but
without any usefull content. More imporatant: Those branches don't get a good
testing like the trunk does. And as trunk is defined as "might be broken" I
have no fear to commit something which might not 100% bugfree. We get more
and more users checking out the trunk (and several of them are Gentoo users
which I count as being experienced enough to submit good brs), so we can use
that power to get testing. If we split the development, the branches wont
achieve that good testing.
Thus a branch should only be evaluated if the changes require a development of
several weeks (with no usable output in between) with constant user feedback.
(Because we must advertise that branch so it gets tested.)
Otherwise I think creating the full commit and then commit it to trunk is much
better.
> - Make a branch in SVN (one branch for one feature)
> - Check in often, the branch must not be stable (but bear in mind the
> next point)
trunk must be neither.
> - Merge every new trunk revision into your branch and fix conflicts, to
> ease merging back into the trunk
Every revision is probably not possible and it would be forgotten anyway.
Doing this in a sane timespan is totally enough IMHO. (Eg currently we have
not much commits to trunk / week) and merging those in a weekly digest basis
or similar is ok, I think.
> - When your changes have stabilized merge back into the trunk
Yes, important one. ;) This one was forgotten on BerliOS so long...
>
> For a release:
> - Make a new tag for the release
Not yet. tags are snapshots which (shouldn't) recieve any changes.
The idea is to create eg branches/2.1 as a release branch for the 2.1 release
series. (Was not practiced yet, because there were not so much changes and
for some time I was alone, so there was no sense. And now we hopefully only
have 2.0 for one more release, so no need anymore.)
Merge bugfixes from trunk back into branches/2.x if they don't include bigger
(possibly breaking) changes to the structure.
> - Prepare a release candidate:
Min 2, must be in testing for at least 2 weeks each. (Because userside testing
is slow here.)
> - Run ./autogen.sh and add the generated/modified files to SVN
This would be the last step I'd do actually.
And I don't know if the files should be in SVN. (Would break the tags rule.)
See *
> - Edit configure.ac, win32/warzone2100.rc (other files?) to include the
> correct version
I don't think there are others and there really shouldn't be more. (They tend
to be forgotten as you might have noticed from my "oh sh* I forgot something
commits to the tags/ dir.)
> - Make a source tarball, autopackage, Windows installer
That's what I did actually. We also need a diskimage (MacOSX). And those tasks
could be distributed over several ppl if needed.
> - Announce it on the mailing list, forum, home page, web sites:
Forum and homepage are using the same base for news (the announcements forum).
News in the announcements forum are directly shown on the mainpage.
> - linuxgames.com
> - happypenguin.org
> - freshmeat.net
> - linux-gamers.net
> - If there are bug reports, fix (and possibly merge the fixes into the
> trunk as well) and repeat
Other way round. Fix in trunk, merge back to branches/2.x
Wait for the release candidate cycle to finish (2 weeks).
> - Else: Release.
> - If a serious bug is found, fix and make a bugfix release (with a
> letter appended to the version number)"
No, I don't think that is sensible. It would be better to throw a new bugfix
release out than adding another subnumber to the version.
I fixed the version scheme to: x.y.z{_ext}
x: Major release. Something groundbreaking like Pumpkin -> GPL
y: Minor (/Feature) release. New features and other bigger changes go here.
z: Bugfix release. Only bugs have been fixed. (I also thought about skipping
that completely and only having a x.y scheme, but Per convinced me that
bugfix only releases are not bad.)
_ext: Extension for release candidates with number (_rc1, _rc2, ...) Maybe
also _beta123 and similar. I did that Gentoo Portage conforming and I don't
think that was a bad descission.
>
> I have changed the release procedure a bit. My goals:
> - Make a tag to release from so development can continue on the trunk
> without destabilizing the release
Jup. Just replace tag with branch and that is the idea we have for the 2.1
series.
> - What's in SVN gets into the tarball, so checking out the tag is equal
> to getting the tarball
We need to figure out what about the autohell files.
> The last revision of the tag is the best version of the release, and
> ideally the release itself.
Nope. tag rcs and the release seperate.
eg:
tags/2.0.5_rc1
tags/2.0.5_rc2
tags/2.0.5
That way it is always crystalclear what revision a candidate was and we don't
get those problems like on BerliOS where we didn't knew if a bug might
allready have been fixed.
>
> So lets say we want to release 2.0.6:
> - Make tags/2.0.6
> - Release 2.0.6-rc1
> - Fix bugs
> - Release 2.0.6-rc2
> - No bugs found
> - Release 2.0.6
> - Fix an important bug
> - Release 2.0.6a
> For the next round copy the trunk to tags/2.0.7.
>
> About the branches, we have SVN, so lets use it. Having a branch instead
> of developing solely on ones hard disk has (at least) two advantages:
> - Changes can be checked in often, so the patches are small compared to
> one complete patch adding a new feature (useful for bug fixing)
> - People can test the branch and report problems earlier
That's my argument for not using too many branches. :P
Spliting of resources means always less resources for the single parts.
* My current idea is to evaluate waf to be used instead of autohell in 2.1
This would reduce the scriptsize drastically (700kB -> 70kB or something like
that. I compared the sizes long time ago.), wouldn't require extra configure
scripts, wouldn't require a special version of autohell (just Python instead)
would work thus natively on Windows, Linux and MacOS.
This would make it not needed to run any ./autogen.sh script, so what would be
in SVN would allways be what is in the tarball.
--Dennis
pgpVYoqTSQ3Gv.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
