Hi Ivan,
>>> On 7 September 2015 at 18:47, Stefan <luke1410_at_gmx.de> wrote:
>>>> Hi,
>>>>
>>>> I'm pleased to announce the availability of a new distribution of SVN
>>>> called: "MaxSVN".
>>>> In contrast to other SVN distributions this one is a bit different since
>>>> it
>>>> aims towards being used primarily to support SVN development rather than
>>>> being used in production environments.
>>>>
>>>> Its primary purpose is to test and identify issues of SVN against the
>>>> latest
>>>> build tools and dependencies on Windows.
>>>>
>>>> It can however also be useful in other situations like if you wanna check
>>>> whether a current development branch solved a particular issue or to
>>>> check
>>>> out the new features in an upcoming SVN release before it becomes
>>>> available
>>>> as part of a final release.
>>>>
>>>> Please note once more that I strongly suggest against using MaxSVN in
>>>> your
>>>> daily productive use. Please stick with one of the already available
>>>> Windows
>>>> distributions. A list of these can be found on the MaxSVN webpage:
>>>> http://www.luke1410.de/typo3/index.php?id=97
>>>>
>>>> Also understand that MaxSVN is a product distributed, maintained and
>>>> created
>>>> by myself and is not directly associated with the Apache Subversion
>>>> project.
>>>>
>>>> The latest current available builds are:
>>>> - 1.7.22.2 (current latest 1.7 released version)
>>>> - 1.8.14.2 (current latest 1.8 released version)
>>>> - 1.8.15.1 (current 1.8 preview version)
>>>> - 1.9.1.2 (current latest 1.9 released version)
>>>> - 1.9.2.1 (current 1.9 preview version)
>>>> - 1.10.0.2 (current 1.10 preview version)
>>>>
>>>> Feel free to send any feedback directly to me by mail or use the
>>>> bugtracker
>>>> at http://www.luke1410.de:8090/browse/MAXSVN to add bugreports/feature
>>>> requests.
>>>>
>>> May I suggest to rename branch and trunk builds version to something
>>> like 1.9.x-dev-rXXXX and 1.10.x-dev-rXXX? Never replace 'x' with the
>>> current version patch version. I.e. '1.9.x-dev-r1701757'.
>>>
>>> Because versions like 1.9.2.1 may confuse users. It's very hard to
>>> find difference between 1.9.1.2 and 1.9.2.1 to distinguish official
>>> releases from development builds.
>>>
>>> Thanks!
>> I agree with u that the version numbering is not too clear and I also tend
>> to agree that adding the revision number to the version number makes sense
>> given the target audience of MaxSVN.
>>
>> If I understand u right, then u are suggesting not to use SVN's patch
>> version in MaxSVN version numbering scheme. I thought having that directly
>> in the version number available would actually benefit users, because they
>> would directly see which SVN version a MaxSVN version is based on.
>>
> You are understand my correctly. My point that you cannot call
> something build from 1.9.x branch as 1.9.1 or 1.9.2. The only build
> from official distribution or tag should have patch version in version
> number IMO. For example at which point you're going to change patch
> version of branch builds? We change it at arbitrary time: sometimes
> it's done immediately after creating, sometimes later.
My current process is that once a tag-version becomes available (let's
say 1.9.2), the next build from the branch would increase the patch
number in MaxSVN (in case of 1.9.2 being released, the next
1.9-branch-based build would be 1.9.3.1 (in the current scheme)).
Reasoning for this choice is that the development is on the path to a
following 1.9.3 release and all MaxSVN builds on that path to that
version are represented with that (potentially) targeted next version
number (aka 1.9.3.x).
I understand the current SVN release process includes a version bump on
the branch at the point a new version is tagged, is that wrong?
Since MaxSVN won't make builds of branches which (code wise) match
tagged versions (i.e. 1.9.3.1 would not be build for as long as the
1.9-branch equals the 1.9.2-tag), there should not be much an issue
here. Or am I missing something?
>> I also think that Bert's suggestion to use the "dev" marker for versions
>> which are based on a not-yet released build is quite good and drop that
>> marker once a build is based on a released version.
>>
>> What's ur opinion on using the following scheme instead:
>> 1.9.x-y-rxxx-dev for versions not yet released
>> 1.9.x-y-rxxx for versions based on SVN versions which are already released
>>
>> x is the current minor version of the SVN version
>> y is a running number for MaxSVN builds
>> rxxx is the SVN revision a build is based on
>>
>> So in case of the current 1.9 MaxSVN releases this is how with the other
>> scheme things would look like:
>> 1.9.0.1 -> 1.9.0-1-r1692833
> What is the reason to include revision number for tag builds? In this
> case you reduce difference between tag and branch builds, which may
> increase user confusion. IMO tag and branch builds should be very
> distinguishable from each other.
Good question. I didn't put too much thought into that one. Just went
with consistency. But I agree that dropping the revision number for
tag-based-builds would make it more obvious to the user which version is
a dev-based and which one is a released-based version.
>> 1.9.1.1 -> 1.9.1-1-r1694136-dev
>> 1.9.1.2 -> 1.9.1-2-r1698174
>> 1.9.2.1 -> 1.9.2-1-r1701493-dev
>>
> I find proposed scheme very confusing for users. It already confused
> users on tsvn-users list: they have an impression that 1.9.2 is
> already released, because they noticed 1.9.2-something builds on your
> website.
Right, I remember these issues with TSVN on the lists and the confusion
they add...
However, that's exactly the reason which made me come-up with the idea
to keep the full SVN version number as the first part in my scheme.
Aiming for it being obvious to the user which SVN version a MaxSVN
version is based on (preventing the issue which happens to TSVN).
What would u say about this other scheme:
1.9.1.1 -> 1.9.1-1-r1694136-dev
1.9.1.2 -> 1.9.1-2
1.9.2.1 -> 1.9.2-1-r1701493-dev
i.e. 1.9.1.2 is a tag-based build on the 1.9.1 branch (therefore it
won't suffix the revision number and dev suffix).
Given that change, I'm even thinking whether the -dev suffix is still
required in the version number or whether it can be dropped completely
as in:
1.9.1.1 -> 1.9.1-1-r1694136
1.9.1.2 -> 1.9.1-2
1.9.2.1 -> 1.9.2-1-r1701493
Any thoughts would be very much appreciated.
Regards,
Stefan
Received on 2015-09-17 00:30:34 CEST