[squeak-dev] Supporting releases (Re: I Want Keith...)
Andreas Raab
andreas.raab at gmx.de
Wed Feb 17 08:06:21 UTC 2010
(my last message for tonight; promise :)
keith wrote:
> What particularly annoyed me about the boards actions was the fact that
> mantis is no longer tracking against 3.10.2. This is the biggest recent
> loss for the community, it means that the community has given up,
> (without thinking or discussing) the idea of formally supporting
> existing released images, and this is a HUGE step backwards. A fix on
> mantis which loads into and is tested against trunk is of no use to me,
> I maintain that all fixes should be published to mantis against the
> released image, and that trunk dilutes this in favour of some new future
> release in which all will be fixed if you wait a year or two.
That's not an insurmountable issue if we're willing to work out a
reasonable process. Let me try a straw man proposal: Let's assume that
there's a widely open, free for all, development area called "the
trunk". What goes on here is not for public consumption quite yet, but
rather the current development head. There may be bugs filed against
that head but it's not a requirement since development is ongoing and
you can just commit a fix to keep things simple and straightforward.
Come release time, we create a new repository for the release. We copy
the packages (perhaps when we reach RC status) and only update it with
fixes until released. At that point, the release repository is no longer
open for development, and generally development continues in the trunk.
Any bugs that are found against the published release have to be filed
against Mantis simply because there is no open development branch for a
past release.
At a certain point in time (say, every six months or) we harvest Mantis
by looking at all the bugs for the released Squeak version(s) and see
if they have been fixed already (by providing change sets, or in the
latest code). We decide which ones we leave open (unresolved), which
ones we acknowledge (but don't fix) and which ones to include in a new
point release. We commit the agreed upon fixes for the point release
into the repository and make it accessible as update as well as download.
Would this work for you? The idea is to combine both the free-for-all
easy access trunk development with managed bug fixing for released
versions. I'm all in favor of the latter (just as long as it doesn't
prevent the former). And obviously, this model can be applied
retroactively to produce 3.10.3.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|