Re: Future squid development

Andres Kroonmaa wrote:

> If non-dev people create a feature they need, they want to see it appear
> in the next FEATURE release that is based on good old STABLE and is not
> touched with any radical changes. If they can't easily commit their changes
> to developers, they either have to maintain their patches on their own or
> enter HEAD development. If neither is inconvenient to them, they stick with
> their old STABLE with their patches and will not submit their changes to
> developers at all.

Then have your feature based on the 2.3.STABLE source tree.

However, if you want it to also appear in 2.4.STABLE then someone has to
do the porting of the code to the new release, and it is quite likely
that this will not be an easy task when development has moved on for a
while. This merging is by far easies done by the one who wrote the
change, and quite close in time to when it was written.

So I am afraid that what you propose will easily end up in a situation
where 2.3.FEAT has features which will never appear in any future
releases, forcing people to stay with 2.3.FEAT even when there is a
2.4.STABLE. Personally I think this is a far worse feat for a
development than not having early access by other users not daring to
try something based on HEAD..

But I will consider your ideas, and try to figure out if there is a
manageable and clean way of doing it. The basic idea is sound. The
problems is in how to actually do it without ending up in dead ends as
development moves along in incompatible directions on both branches.
From a development cycle point of view I beleive that the best approach
is to have a FEATURE branch where useful changes from HEAD gets
backported by someone who takes active responsibility for this branch.
This is defenitely doable, but requires a mantainer that knows both
versions.

/Henrik
Received on Wed Oct 04 2000 - 13:23:49 MDT