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?
> > - 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?) 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, so I can see
"That's nice, I'll try that" (for a feature) or "Oh, that might break
things" and can wait for a fixed revision (if I don't want to bother
myself).
> > For larger changes:
> Very large changes. As we see on BerliOS we can have dozens of branches, but
Yeah. I meant for things like "OK, let's try to replace the widget
system" or other changes that'll leave the tree in an unusable state for
a longer time. Not "OK, let's make a branch for me and I'll see if I can
do anything with it". A branch needs a purpose, and once that's served
it gets merged back into the trunk.
> 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)
I agree...
> 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. 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. 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).
(And just to mention it again: I'm neither lawyer nor politician, so
everything I write is my own opinion.)
> > - 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).
> > - 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."
Hmmm... thinking about it, I don't really care how it is done, as long
as the conflicts are solved. But I'd rather fix those revision by
revision instead of all at once.
> > - When your changes have stabilized merge back into the trunk
> Yes, important one. ;) This one was forgotten on BerliOS so long...
Yes. And I'd now change it to "As soon as your changes..."
> > 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)).
> Merge bugfixes from trunk back into branches/2.x if they don't include bigger
> (possibly breaking) changes to the structure.
Good point.
> > - 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.
> > - 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?
> > - 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.)
I know, that's why I included it here (the ChangeLog as well).
> > - 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.
> > - 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).
It just makes more sense to me to fix a bug in the source it occured in
(the release) than in the trunk, which might have changed a lot since
the 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.)
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). A bit inflationary on the y number,
but who cares if we have 2.23.41 sometime? As the x is reserved for
something groundbreaking, 3.0 will be the perfect Warzone, totally
rewritten. ;-)
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. Just
save yourself the hassle and do without them - if something breaks, do a
new release. No worries.
> > 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.
> > - 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. ;)
--
"The Bitterness of poor quality lingers long after the sweetness of low
price is forgotten"
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
