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:
> >>>
> >>> On 19/09/2015 22:00, Johan Corveleyn wrote:
> >>
> >> ...
> >>>
> >>> So what is your suggesting then? I doubt that adding a "-dev" suffix to
> >>> the
> >>> version number (which is only recorded in the bugtracker and in the
> >>> changelog) would actually solve ur underlying concerns, or would it? If
> >>> so,
> >>> I certainly can do that.
> >>>
> >>> But I guess the concern lies deeper here and you don't want any
> >>> distribution
> >>> being made available to a wider audience of those versions which you
> >>> haven't
> >>> released yet. Am I reading that correctly between the lines? If so, I
> >>> guess
> >>> there is no point in further advancing the MaxSVN idea here, because it
> >>> would basically mean that it's not adding much to the already existing
> >>> distributions.
> >>
> >> No, that's not what I meant at all. Stop reading between the lines
> >> :-). I like your efforts to bring early builds to a wider (developer /
> >> expert / ...) audience. I think it's a good thing.
> >
> > ;-) - so gonna try to stop that habit (aka: reading between lines), but no
> > promises I succeed
> >>
> >> 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.
Cheers,
Daniel
> BTW, thanks for doing this, I think it's very useful work (especially
> since building SVN on Windows is so hard). And thanks for your
> patience in talking these details through with the dev community.
Received on 2015-09-21 23:10:14 CEST