Ross Gardler wrote: > Johannes Schaefer wrote: > >I was wondering if updates to released versions get "built" > >and result in a new "binary" to download. > > > >I do *not* mean plugins here (see discussion below), > >I mean changes to forrest core. > > Ahhhh... I musinderstood. > > >Other OO projects do so, e.g. if there is a security issue > >(e.g. Firefox 1.0.7, then 1.5). > > Yes, the key point is thet there needs to be a compelling reason to do > it. There is considerable effort involved with doing a release it is not > simply a case of packaging and making it available for download.
Yes, big effort. It also needs the full testing and vote process and co-operation of the PMC. It would not be as bad as doing a major release (e.g. 0.8) but still a lot of effort. [1] [2] > >When should such an update be done? > >For critical bugs? After each "minor" comitt (like mine today)? > > My opinion would be critical bugs. Minor commits would wait until the > next "major" release. Another reason might be that we take too long to do the next major release, or strike a big impediment. Like Ross, i would rather put the effort into getting 0.8 out. > Of course, if an individual dev has a personal/business reason for doing > a release and they are willing to put the effort in, it is unlikely that > anyone would object. There is an alternative, if your clients cannot manange to use svn to keep up-to-date with the branch. If any developer (not just committer) needs to, then they can package the product themselves. Don't call it a product of our project. It is just some private distribution. Just follow the procedure in [1], but build a private package giving it a good name, e.g. forrest-0.7.1-dev-20051221-r358425.zip There are a lot of steps that you can leave out, which should be obvious. Alternatively you might get away with just zipping up the contents of your current forrest_07_branch working copy of svn. > However, most devs (well, only me for certain) > would prefer to focus on 0.8 rather than spend time on a 0.7.1 release > > (unless there is a critical issue involved). Me too. With a small project we need to focus on trunk. [1] etc/RELEASE_PROCESS.txt [2] http://forrest.apache.org/guidelines.html#actions We really need to document this. I made some links to similar email discussion: http://forrest.apache.org/guidelines.html#develop -David
