Hi Ivan,
On 7 September 2015 at 18:47, Stefan <luke1...@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
