Branko ÄŒibej <brane@xbc.nu> writes:
> Greg Stein wrote:
>
>>This change implies a variance in the release process. Specifically, that
>>post-release, we bump the number. Thus, after a 1.0.1 release, we bump the
>>number so this becomes 1.0.2-dev.
>>
>>
> Yes.
>
>>But I've grown to dislike that pattern. In particular, you might not know
>>what the number is supposed to be. Or maybe you bump it "too far". This
>>happened to me with ViewCVS where one of the committers bumped it from 0.9
>>to 1.0 (so it now reads 1.0-dev). Unfortunately, I'm now stuck because if
>>I try and back away from that, a release will look like it is older than
>>the 1.0-dev installs out there. And I would prefer if the next release was
>>*not* 1.0; there has been too much change which needs to be tested (by
>>distributing a release to the masses).
Another problem is that X-dev doesn't necessarily have all the X
features, so a configure script checking for a particular version X
must either detect and reject X-dev or require Y > X.
Is this a problem in practice? Well, Subversion's own configure
script requires apr-0.9.5 even though apr-0.9.4 would work. That's
because apache-2.0.47 comes with an apr-0.9.4-dev that doesn't have
enough of the apr-0.9.4 features to satisfy Subversion.
> So? If somebody installs something that was not released, that's not
> your problem. I recognize that this happens all the time in the open
> source world, but...
>
>>Thus, I prefer that we continue with the "+" marker to mean "this is like
>>1.0.1, but additional stuff has been changed."
>>
>>
> ...this is a problem: both the tip of trunk and the tip of the stable
> branche(s) must somehow indicate development/unreleased status. In your
> scheme, right after the 1.0 release, _both_ branches would say "1.0.0+";
> and worse, after a 1.0.1 release, the stable branch would havs "1.0.1+"
> and trunk would still have "1.0.0+", which is nonsense to me.
It's unfortunate that they have the same version. However until the
trunk changes the API/ABI the two versions should be compatible, so
it's possible to argue that the matching versions are not a problem.
Once the trunk does break API/ABI compatibilty the it should have it's
version number increased, and the problem goes away.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 31 03:12:30 2004