Evgeny Kotkov wrote on Wed, Sep 23, 2015 at 21:12:19 +0300: > Stefan Hett <luke1...@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
