On 21/09/2015 23:10, Daniel Shahaf wrote:
Johan Corveleyn wrote on Sun, Sep 20, 2015 at 00:00:42 +0200:
On Sat, Sep 19, 2015 at 11:35 PM, Stefan <luke1...@gmx.de> wrote:
On 19/09/2015 22:48, Johan Corveleyn wrote:
On Sat, Sep 19, 2015 at 10:14 PM, Stefan <luke1...@gmx.de> wrote:
I was just trying to say that we've already had "1.10.0-dev" in our
own "version tag" (ever since branching 1.9.x), but that we've never
had to think about this because we weren't distributing it. You've put
us in a new situation, but that's not a bad thing :-). How to name the
binary package that you're putting up for download ... without
creating confusion.
So the suggestion would be to use the scheme based on Branko's, Bert's,
Ivan's and Evgeny's suggestions:
MaxSVN 1.7.22.1 -> MaxSVN 1.7.22-1
MaxSVN 1.7.22.2 -> MaxSVN 1.7.22-2
MaxSVN 1.8.14.1 -> MaxSVN 1.8.14-1
MaxSVN 1.8.15.1 -> MaxSVN 1.8.x-dev-r1701493-1
MaxSVN 1.10.0.1 -> MaxSVN trunk-dev-r1697405-1
MaxSVN 1.10.0.2 -> MaxSVN trunk-dev-r1701565-1
Would that cover ur concerns you raised too?
Yes, I think so (but I can't speak for the others of course).
Putting my user-hat back on, I can see that it can be a tad annoying
that you can't see at a glance that 1.8.x-dev-r1701493-1 is pre or
post 1.8.14-1, but I guess that can be solved best by describing it on
the web-page (and maybe with help of ordering given on your website).
To address this, how about 1.8.14_42-XXX, where:
- 1.8.14 is the upstream release that MaxSVN release is a superset of,
i.e., typically "%d.%d.%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH-1);
- 42 is the number of commits to the 1.8.x branch between 1.8.14's magic
revision and the revision the MaxSVN release is based on (so a build
of the 1.8.14 tag would be 1.8.14_0-XXX);
- XXX is a build identifier.
This will work for stable branches, but I'm not sure what to do about
trunk. In trunk, the issue has nothing to do with Stefan's packaging:
the trunk tree self-describes as being SVN_VER_MINOR=10, but it might
not be compatible with 1.10 GA. I don't think there's a clean way
around that short of adopting the "even == stable, odd == unstable"
SVN_VER_MINOR convention that some projects use.
We could do that tomorrow, really. We'd just have to skip 1.10 and make
trunk 1.11, and the next release after 1.9 will be 1.12, which would be
odd — sorry, I meant to say "unusual" — but if it has a tangible benefit
in the form of reducing user confusion, it might be worthwhile.
To be honest, when looking at 1.8.14_42 alone, it won't immediately pop
into my mind that this is a version newer than 1.8.14 (I'd think it's
some special build of the 1.8.14 source).
Changing that to 1.8.14.42 (or .1 or whatever magic number to be used)
would work better, but then might mislead users in thinking that this is
an official SVN version (aka: 1.8.14.1) rather than some development
build I guess.
Considering the pros and cons of my previous and ur suggested scheme, I
think I'd prefer the 1.8.14_42-x style regardless, because it seems to
be the best compromise between all the different options.
I'm feeling a bit honored here that you are even talking about
considering the option to change ur version numbering for trunk in the
light to make that solve my conflict with naming trunk-based builds. If
in the end it's decided to be changed, I would certainly adapt to that
version scheme for MaxSVN as well.
Until that point, using "MaxSVN trunk-dev-r1701565-1"-style versions for
trunk builds is fine and I can swap this at any point without having to
change the previously released trunk versions.
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
Regards,
Stefan
