Evgeny Kotkov wrote on Wed, Sep 23, 2015 at 21:12:19 +0300:
> Stefan Hett <luke1410_at_gmx.de> writes:
>
> > So unless some new arguments will influence my mind again, this is the
> > version scheme I'd aim for:
> > (magic numbers are temporary, I didn't quite check them yet)
> >
> > MaxSVN 1.7.22.1 -> MaxSVN 1.7.22_0-1
> > MaxSVN 1.7.22.2 -> MaxSVN 1.7.22_0-2
> > MaxSVN 1.8.14.1 -> MaxSVN 1.8.14_0-1
> > MaxSVN 1.8.15.1 -> MaxSVN 1.8.14_42-1
> > MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
> > MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1
>
> I am thinking that 1.8.14_42-1 could be err..., surprising.
>
> Here is what it looks like if I try to put myself in the users' shoes.
> I am looking for Subversion 1.8, and I would love it to work without problems.
> At some point I stumble across MaxSVN, and here is what I see:
>
> MaxSVN 1.8.14_0-1
> MaxSVN 1.8.14_42-1
>
> Perhaps, I could also see this, depending on how the versions are sorted:
>
> MaxSVN 1.8.14_42-1
> MaxSVN 1.8.14_0-1
>
> "The bigger the number the better the build, right?", I say to myself and
> start downloading MaxSVN 1.8.14_42-1. Well, wrong, because it is based
> on a snapshot of the branch and not on the released version.
>
1.8.14_42 is just 1.8.14_0 plus some backports. Assuming that one of
the backports has a bug, if we don't catch the bug within a week of
making the backport, chances are 50/50 whether we'll catch the bug
before or after we cut the 1.8.15.¹ So, practically speaking, I would
think a 1.8.14_42 that is over a week old is as stable as 1.8.15 will
be, when it's released.
The problem with snapshots isn't stability, then; it's that they aren't
covered by compatibility promises. _If_ an on-disk-format bug creeps
into 1.8.14_42 and gets fixed before 1.8.15_0, there might not be an
upgrade path from that 1.8.14_42 snapshot to anything newer or older:
https://subversion.apache.org/docs/community-guide/releasing#prerelease-caveats
So I think you're right: _0 and _42 are fundamentally different, and it
would be good to communicate this difference to users. The most
straightforward way to do this would be to include SVN_VER_NUMTAG in the
version number.
¹ That's just a ballpark estimate.
> So, why not have a scheme that uses tag names when you build from a tag,
> branch names when you build from a branch, and trunk when you build from trunk?
> You could split the builds in two separate groups when presenting to the user,
> say, like this:
>
> MaxSVN 1.9.0-1
> MaxSVN 1.8.14-1
> MaxSVN 1.7.22-1
> MaxSVN 1.7.21-1
>
> MaxSVN trunk-dev-r1704854
> MaxSVN 1.9.x-dev-r1701565
> MaxSVN 1.8.x-dev-r1701493
> MaxSVN 1.7.x-dev-r1700845
>
I think it's useful to have the "latest released SVN_VER_PATCH" value in
version number for easier reference. ("Is 1.7.x-dev-r1700845 before or
after 1.7.22?") So perhaps:
tag build: 1.8.14_0
branch snapshot: 1.8.x-dev-14-r1701565 (where '14' is the latest released value of SVN_VER_PATCH)
And in either case, optionally a build number at the end, if Stefan
decides to include that.
Cheers,
Daniel
> Worth mentioning, I am not that sure about the necessity of having different
> builds (like 1.9.0-1 and 1.9.0-2) based on the same source. You could probably
> get rid of them by only using new dependencies for new builds.
>
> In other words, when you build MaxSVN 1.9.0 and upload it, it is immutable.
> You could then update APR version in MaxSVN 1.9.1, if you feel like it. Doing
> so would turn the scheme into something fairly common and easy to understand:
>
> MaxSVN 1.9.0
> MaxSVN 1.8.14
> MaxSVN 1.7.22
> MaxSVN 1.7.21
>
> MaxSVN trunk-dev-r1704854
> MaxSVN 1.9.x-dev-r1701565
> MaxSVN 1.8.x-dev-r1701493
> MaxSVN 1.7.x-dev-r1700845
>
>
> Regards,
> Evgeny Kotkov
Received on 2015-09-23 23:39:00 CEST