On Wednesday 14 January 2009, Petr Rockai wrote:
> Dan Pascu <[email protected]> writes:
> > I can understand why significant changes should not go into a release
> > the day before it is going out, but come on, even not knowing Haskell
> > I can still read that the patch does nothing more than use putDoc
> > instead of putDocLn (which is putDoc plus an extra line). Such
> > trivial bug fixes shouldn't be put on a shelf waiting another few
> > months before users can benefit from them (do not forget that few
> > people build darcs from source and even fewer build the current tree,
> > most of them just use a binary made after a release or whatever comes
> > packaged by their distribution).
>
> Such trivial fixes, after the release candidate is out, require another
> RC cycle, which is a week. So it's either:
> 1) we slip the release a week, this fix included
> 2) we release on time, and release 2.2.1 in two or three weeks, this
> fix included (and hopefully some other)
>
> I vote for 2. If anyone disagrees, please voice your opinion
> (otherwise, I take the default, ie. option 2).

2 sounds as a reasonable compromise to me. I would not want to ask anyone 
to delay a release for such a small matter. My request was made with the 
consideration that such a trivial fix, that is obvious that it can't 
break anything, can be slipped in even in the last minute.

Just so that I understand the release process better, you say that a 
release candidate will not be released if any change occurs, but it will 
become the next release candidate; then when no changes are made to a 
release candidate over a given time period, it is renamed to final and 
released?

-- 
Dan
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users

Reply via email to