Nicolas Weeger wrote:
Hello.
The other issue is that generally, I'm not seeing so many commits that
having people hold off a week would seem like much an issue.
Well of course we can always wait one or two weeks to add features. But
sometimes it's things we'd rather have people test fast than wait weeks.
Also need to consider the possibility of finding a weird bug weeks after
the release - nice to be able to backport to current stable even after
having a whole lot of commits.
Yes, although that doesn't come up that often.
The simpler approach would not do real branches, just for me to keep a
checked out copy and use that when making the release, and bring over
changes manually that are critical in nature. Problem with that is you
can get the case where there is no version is CVS that directly
corresponds to the released version. However, I suppose in that case, a
branch for any relevant files could be made at that time.
That could work, but you'd also need to send the files to specific
platforms maintainers (me for Windows) to have synchronised releases,
with same code.
I could, if necessary, do a branch commit if there are in fact any files that
are different. But then I suppose the question is why not just do a branch in
the first place.
Of course, within CVS, there really isn't a branch until something needs to be
commited that is different.
We probably want the main (head) stream to continue to be CVS. So by the time
you want a branch, it is in a sense too late (someone has already commited
somethign to the head). An in that case, you don't really want a branch, unless
you make changes - you just want to note that version x.y is what is going in
the main release.
Using tags may actually make more sense.
Right now, when I make the actual release, I tag the files, so you can do
something like 'cvs checkout -r rel-1-7-0'.
But as described about, not until a change happens do you need a branch. So
what should probably be done is at the 'code freeze' time do a cvs tag can-1-8-0
or something. Thus, if nothing changes, that can be tagged again as rel-1-8-0 (
can = candidate, rel=release). So if changes are made to CVS head, no big deal
- the can- tag is still there to get the files to release. If a fix needs to be
backported, the can- tag can be used to find the point to make the branch from.
But what it really comes down to is that it is more work for the person
doing the release (me), and I really don't want to make things any more
complicated for myself - I'd much rather be dong stuff more worthwhile
than syncing up branches.
On the other hand having a branch lets more people contribute to fixing
bugs on that release, anyone could backport as opposed to your scenario.
Also, I don't think there's a rule in stone saying only you can do
releases, is there? :) I'm sure we'd find people to help for that. I'm
also pretty sure CVS helps a lot for merging changes.
If other people want to help with releases, that would be great. Having a
more frequent (quarterly) release schedule would also be good.
Even people taking some portiosn of the release (maps, archs) reduces the
effort a bit on my side - those bits aren't really hard, but if I save myself 15
minutes, that is always nice.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
