Stefan wrote on Wed, Sep 23, 2015 at 08:39:24 +0200:
> 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 <luke1410_at_gmx.de> wrote:
> >>>On 19/09/2015 22:48, Johan Corveleyn wrote:
> >>>>On Sat, Sep 19, 2015 at 10:14 PM, Stefan <luke1410_at_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).
In a sense, it is: it's a build of 1.8.14 plus some patches.
> 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.
>
Like I said, I consider it is our problem, not yours, to assign trunk
a version number that doesn't cause problems to downstream users.
> 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
>
Sounds good to me :-).
As I mentioned on IRC, the one remaining edge-case in this scheme is
what to call releases from branches/1.10.x before any 1.10.* pre-release
has been announced. But hopefully that will also be solved by us by
simply releasing a 1.10.0-alpha1 when the stable branch is created (or
before that).
Cheers,
Daniel
> Regards,
> Stefan
Received on 2015-09-23 15:18:10 CEST