Am Samstag, 16. September 2006 23:33 schrieb Christian Ohm: > On Wednesday, 13 September 2006 at 0:21, Dennis Schridde wrote: > > 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.) > > Well, it can't hurt to list it there, can it? It can. If you read carefully you see the sentence about the "regular interval" and the explanation why this could be safer is given in brackets right after that.
And having rules which noone follows doesn't help either.
> > > - 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.
>
> (what's br?)
BugReport
> So when the wiki page is gone, the information is gone as
> well. Not good. I'd rather have those sent to the SVN-list,
But also you can't include a whole Wiki in your commitlog...
> > 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.
>
> ...up to here. I don't like large "this is what I did last summer"-patches.
I know what you did last summer.
> Those just make it more difficult to review and (in
> case it's necessary) look for bugs, while a merged branch has a more
> detailed history.
Jup... Sounds reasonable.
But I guess for the next version we will change a lot anyway, so probably
there will be more than enough subsystem changes. Don't know yet how to
handle that...
> Besides, I find it useful to have my changes
> version-controlled while working on something (and it's not really
> convenient to have to use Darcs (or whatever else) besides SVN).
>
> Testing the changes in the branch is a nice side-effect if it happens,
> but not the main purpose, and testing will happen as soon as the branch
> is merged back into the trunk (that should happen as soon as possible).
But if that breaks a lot (you didn't catch before because of missing testing)
you have a broken trunk...
So if we branch we probably have to keep in mind that merging it back can
break a lot, simply because we didn't catch all the bugs in it.
> > > - 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.
>
> But it should not remain that way for long, since there are people using
> it (as you said yourself).
As those people don't expect a trunk to be stable it doesn't matter.
(They only care about the trunk compiling, so that needs to be taken care of.)
> > > - 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.
>
> That sounds kind of backwards. With few changes it's easier to merge
> every revision separately than with several per day. But I see what you
> mean; let's change it:
>
> "Periodically merge the trunk into your branch to ease merging back into
> the trunk. In case of (non-trivial) conflicts merge the conflicting
> revisions separately."
Sounds good.
> > > 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
>
> OK, that way works as well. Then let's say something like "Make a
> branch for the release, and a tag for the released revision."
>
> What I wanted to avoid was always releasing from the trunk. That keeps
> people from working on the trunk (I think I read in the IRC log that
> Troman was holding back some changes because of the release), or adds
> more than trivial changes between release candidates (and that's not
> really the purpose of a release candidate (depending on the definition,
> as always)).
I know. Was my mistake. (Or my missing experience with releasing.)
Wont happen with those branches again.
> > > - Prepare a release candidate:
> >
> > Min 2, must be in testing for at least 2 weeks each. (Because userside
> > testing is slow here.)
>
> Seems a bit slow to me, four weeks until a real release. In my opinion,
> a release candidate is used to find the more or less obvious bugs, not
> as much bugs as possible. That'll happen in the release anyway. That
> leads to another idea, see below.
See below...
> > > - 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 *
>
> Yeah, it's not ideal, but then, the autostuff isn't. Let's just replace
> it, OK? It's just too annoying to work with. Do you need any help with
> your waf evaluation?
Compilation with waf was never a problem. Only "problem" I currently have is
with the "autoconf" stuff. Means detection of libraries.
That one currently has an odd API in waf and I expect it to be changed not so
far in the future...
I can create the configure module with the current API (a bit "von hinten
durch die Brust ins Auge" (if someone can translate that too good english, be
welcome) but it works).
> > > - 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.
>
> OK. Can you make a pseudo forum member with the mailing list address?
> Then one forum news will take care of that.
That's an interesting idea... Will have a look at it when the server is back.
> > > - 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
>
> I'd say: Fixes for bugs found in the trunk are merged from the trunk (if
> possible), and fixes for bugs found in a release are fixed in its branch
> and then merged into the trunk (if possible).
If the branch differs a lot from the trunk then that sounds better.
But I remember a problem we had on BerliOS. We had changes in !! tags/ !! and
they didn't get merged back into our development branch... With that rule I
tried to enforce it. Perhaps it wouldn't have worked as expected.
> > > - 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.)
>
> Hmmm... By that logic, this (and I guess most other) releases should
> increase the y, since it contains new features, and then you have the z
> for bugfixes.
>
> So the procedure would be the following (I'll take 2.1 as example, but
> it could be 2.0 as well (starting with 2.0.5 instead of 2.0.0)):
>
> - when the trunk is in a releaseable state, make branches/2.1
> - release & tag 2.1.0
> - fix bugs (from bug reports and from the trunk)
> - release & tag 2.1.1
> - fix bugs
> - release & tag 2.1.2
> and so on.
>
> The next time the trunk is more or less stable, start the same with 2.2.
>
> That way you actually have the version numbers represent what you wrote
> above (and no need for _whatever).
I think I mixed up 2 different systems I had in mind.
This is also why my RCs had to be in testing for several weeks:
x.y numbering scheme, no z bugfix releases.
Have features in every release (like we have currently) and instead of
releasing bugfix only releases, release RCs before the final release so bugs
get fixed.
Means:
- when all features are in: branch 2.1 and tag 2.1_rc1
- fix bugs
- tag 2.1_rc2
- fix bugs
- tag 2.1_rc3
- no more bugs: tag 2.1 and release.
- do some development of new features and then branch 2.2 and tag 2.2_rc1
...
This scheme would match the one found in many commercial games I know of.
This way you know when something is relatively bugfree (x.y) and when it can
contain bugs (x.y_rcZ).
The other way you know when there are new features (x.y) and you know when
bugs have been fixed (x.y.z) but you don't know when it has stabelized.
> A bit inflationary on the y number, but who cares if we have 2.23.41
> sometime?
Kernel has, too. ;)
> As the x is reserved for something groundbreaking, 3.0 will be the perfect
> Warzone, totally rewritten. ;-)
Hopefully not.
> There are no release candidates (what I hinted at above), just bugfix
> releases. Why do we need release candidates, anyway? As I said, there
> will always be bugs in a release, no way around that. The release
> candidates just need more time, and fewer people will test them.
I didn't take into account the psychological effect of an "rc" in the name...
Might be true. Now I stated the 2 concurring schemes above. Don't know yet
what we will really take and which is better.
> Just save yourself the hassle and do without them - if something breaks, do
> a new release. No worries.
That one sounds good. ;)
> > > 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.
>
> Tag, branch - it's all the same in SVN, it just has different names.
And different meaning.
Tags are snapshots and branches are ongoing development. And it should be that
way, because otherwise we just confuse other people, like we did with
branches/crossplatform on BerliOS. Or like Quamly did with me when I looked
at his tags/0.2.3 when I tried to create a ChangeLog for all releases.
> > > - 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.
> Purgatory.
>
> Oh, by the way: Most of the things I propose are based on watching
> (mostly) this project work (or not), not just pulled out of thin air. ;)
Jup. Do the same with my own proposals. ;)
And I think most of your proposals are good, but as in daily politics there
are sometimes many ways to approach a problem and you don't know in advance
which one is better. :(
--Dennis
pgpKPfFHok8Jv.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
