[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