On 2 Oct 1999, Lars Gullik Bjønnes wrote:
>
> We have finally been able to end the 1.0.x series, and has opened up a
> new 1.1.x series. We expect all releases in this series to be stable.
We should send an official PR to Linux Weekly News and maybe Freshmeat as
well simply explaining the switch from a Linux Kernel style numbering and
release scheme to one more like that of Fetchmail ie. rapid releases of
stable code.
However, we first have to decide whether or not we really are going to be
changing[see below]. Now that 1.0.4 is out if we take this new series
seriously then there will never be another 1.0.x release again. Since
1.1.1 has everything that 1.0.4 does. Any bug fixes for 1.0.4 should be
done in 1.1.x. We need to get the new string/autoconf stuff stabilised
rapidly and then encourage our users to move to that release (which in
Fetchmail terms would probably be 1.2.0).
This could mean that gui-indep might be achieved by 1.50.0 but don't let
the numbers worry you. It's a different numbering scheme after all.
> PS. Some of you might remember that we had an old 1.1.x series too,
> this has been ditched. But a lot of the changes done in the old 1.1.x
> series are changes that we want, so we will be merging them with the
> new 1.1.x series that is based on 1.0.4.
The rapid but stable merger of the existing experimental work is a key
point for any PR. My major concern is to ensure that everyone realizes
the significance and understands the change of numbering/release scheme
(including developers).
Oh, I should also say that I think we should skip prereleases once the
string/autoXXXX stuff is stable. This is the only major transition stage
we'll have then the Fetchmail numbering and release scheme should take
over -- JMarc and I seem to be in agreement about the x.x.0 scheme anyway.
Allan. (ARRae)
[below] By this I mean that we should not simply consider this a change
from a long development cycle to short one but a more radical shift to a
stable/reliable, constantly-developed platform. Since the core developers
will each be working on one or more branches (assisting each other for
example) and those branches should be quite stable when they are merged
into the main branch each release will in essense be a milestone marking a
new stable feature or revised component. Each branch will contain only a
small change so getting it stable and correct before adding it should be
quite simple. Hence, we'd have a stable, reliable platform that is under
constant development.
P.S. I've probably just written the first draft of the PR ;-)
