On Mon, 19 Jan 2004, Aidas Kasparas wrote:
> OK, I recognize I forget to think about interface compatibility. Can you
> forgive this sin of beginer project developer for the first time,
> please? I promise to learn from this mistake.
I can, indeed :-) If only it gets fixed ;-))
> And I would like to have a little discussion about version numbering,
> syncronization with KAME's code, time for new releases and branch using
> policies.
>
> In 0.2.3 Informational Exchange is broken on all architectures where
> number format is not in network order. Therefore I think 0.2.4 should be
> released soon with endianness fix. Or 0.2.3.1? (I vote for the former)
It should be 0.2.4. There is no need for having an extra dot. But wait, I
have two more pending patches that I want to put in before the next
release :-) [will do it in few minutes]
> Re: sinchronization with KAME. I would like to see our codebase as
> little diverged from KAME's as possible. Exceptions are new features
> developed in separate branches. But racoon and setkey config files had
> change in the past (dramatically, at least once), so I would bet
> incompatible change which went to CVS is not the last one. What should
> we do in that case? Ignore that change on the branch? Automaticaly bump
> middle number in version? On which branch to do this? Should we add
> warnings that this feature will change in next x.y+1.1 release?
I can only say how I'm used to do things (and how many "big" projects,
like GDB, do it): The development is done on the mainline. It doesn't have
to be stable at every minute, but it should be. From time to time
maintainers decide to make a new release. This is usually triggered by
addition of some interesting features, rewriting of the core, etc. Then a
release branch is created in the CVS. While people are quite free in
comitting to the mainline, there are stricter policies in comitting to the
release branch. It is usually called "stabilisation", i.e. catch as many
bugs as possible. As soon as the branch is stable enough, new version is
released. After that no new features (except for obviously simple ones)
should go in, no big unreviewed commits and definitely no interface
changes. Commits to the release branch are mostly only bugfixes. People
should feel safe when upgrading from x.y.1 to x.y.2. If you want to put in
somthing instrusive (like the huge KAME-sync patch), do it on mainline. If
people want to test it, they could (I know that Derek doesn't like the
idea, but we may release snapshots of the mainline for this purpose), but
don't possibly break other people's setups.
Of course we can agree on a different policy...
> Problem with current MAIN branch is it contains initial development of
> NAT-T code by Derek (setkey and libipsec directories). Changes here do
> not affect how things work without NAT-T, AFAIK.
IMHO it's not a problem. There is simply some extra code that noone will
notice.
> Yet, I find 0-2-branch
> to be better candidate for becoming 0-3-branch (either renamed or not)
> until complete NAT-T code will go into MAIN.
Branching from a branch is not a good idea. Let's cut a 0.3 branch from
the mainline, give out some pre-0.3 tarballs so that people have some time
for testing and release 0.3 based on this branch. For some time we can
also support 0.2 branch with security fixes, but we shouldn't base a new
release on it.
> About release time. Security fixes and broken releases are obvious
> triggers. But how much of not so important fixes should go into
> MAIN/branch for new release to be made?
If there is a security fix that can be applied in the release branch, then
just make a new sub-release (e.g 0.2.4). If there is a big improvement
(e.g. huge KAME-sync, or a new functionality like new generate-policy)
made in the mainline and things are stable again, then release a new
version (e.g. 0.3).
> How strict is our policy regarding interface changes where version
> number changes only after last dot? Do we consider "interface change" if
> a) extra warning/diagnostics is added?
Hmm, it depends if it can be switched off to make it backward compatible.
> b) changes affects only parts which are for debugging/testing and should
> not be used in production (debug mode/ weak crypto)?
It is definitely an interface change.
> And finaly, what is expected to happen with this checkin? Should I
> remove it completely (with all the leak and other fixes) and expect that
> 0.2.4 will be the last 0.2.x?
> Should I rework for interface to be not
> changed [in case you pointed are 2 points where break is: 1) simple do
> not need argument and setkey no longer expects argument after "simple";
> 2) message "obsolete algorithm" is promoted from warning to error]?
If it wouldn't be too much work then only extract the obvious bugfixes
from the patch and revert the rest. If someone feels the need for new
features brought by KAME-sync he should use mainline instead (it's always
good to test a codebase for future releases).
Any other opinions?
Michal Ludvig
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
|