forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: fixing bugs in trunk or branch
Date Tue, 08 May 2007 05:20:35 GMT
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

Mime
View raw message