Gav.... wrote: > Ferdinand Soethe wrote: > > > > I'm sorry to have stepped out of line. I hadn't found Cyriaques solution > > when I looked for it. So I tracked down the bug on my own (in far too > > much time) and wanted to share the work with others. That's all. > > I don't recall this sort of thing being discussed before - patching earlier > releases - though David has been doing some doc updates relative to this on > occasion.
Yes it has been discussed before. There seems to be a slightly different aspect to it this time. In the absence of someone reviewing the past threads and documenting it, i have been trying to add links to some of them here. http://forrest.apache.org/guidelines.html#develop It is a big downfall that we have not documented such stuff. It causes us to continually re-visit. This community is too small to cope with ongoing discussion. > No apology needed as far as I can see, we need to discuss it now to be clear > what should and shouldn't get done. The intention is good. We need to include the past discussion. Please let's document it this time. > > What I don't get: Had I found Cyriaques solution and copied it in .7 > > what would have been different? It still would have required testing > > give that .7 is a different environment that .8. It still would have > > only been me to test it given. > > > > We still wouldn't be sure that it really works. > > > > And I may be mistaken here but I thought the version I fixed is a yet > > unreleased update to a released version. Not? > > This is true, there is a doc trail missing here though, how do current users > of 0.7 know that this patch is available, where is the patch to be provided > as an official download for current 0.7 users, what is the process for > releasing patches for earlier versions, do we need to vote on a patch > release etc etc... So many questions in one sentence. I will try to quickly explain. Please see the archives for more. If someone finds a problem with an old release which sufficiently bothers them, then they can provide a patch for the old release. We can apply it to trunk and to the relevant release branch of SVN. They can checkout from svn. Alternatively they can find the change in the svn mailing list and apply it to their downloaded copy of that release. Normally we don't bother to do any further releases of such a branch. Sure if there is a big problem like there was with the 0.5 release, then we do. Committers can tinker with old release branches if they want to. Any developer can create their own private package of a branch for their clients that cannot manage SVN. Do 'cd main; build release-dist'. Changes that are considered important enough to be also added to a release branch, should be noted in the status.xml files. However there is a problem here. We need to also add such entries to trunk's site-author/status.xml because that is what creates the website changes.html doc. If there is sufficient demand, then we can create an actual release of a release branch, e.g. 0.8.1 However it would need to be a very good reason. As you have seen it is a lot of effort. We would do better to release trunk more often and encourage people to upgrade. Ideally we don't manage any "release branches". See Nicola Ken's proposal linked at the abovementioned guidelines doc via FOR-631. Unfortunately we have not implemented that yet. > The downside here is , you can see what extra work will be required to keep > maintaining and patching updates for 0.7, this takes away time from the > current 0.8 release which I guess we will maintain for a while, and also > trunk. We really only have the resources to focus on trunk. > > P.S. One thing I really really disliked about commercial software was > > the fact that you were always forced into upgrading because bugs would > > only get fixed in new releases. > > I guess there will be differing opinions here, new releases come about as a > result of two things mainly, new features and bug-fixes found in older > versions. How far back does one go in maintaining older releases? > > Finally, these are 0.x versions, they are really beta/minor releases, and as > such, open source or not we are not bound to keep users of previous versions > happy, they know the risks. We provide an update path to 0.8. Agreed. > My 2 cents, leave 0.7 alone and lets concentrate on 0.9-dev, ... I agree. > ... if we find > things we can apply to 0.8 then fair enough, ... Only if there is a call for it to be applied to an old branch. > we need to have a patch-release > system for current users of 0.8, not just patch 0.8 for those that have not > already downloaded it. I disagree, see above. -David
