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 <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).
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
