sebb>AFAIK, JMeter has used SVN tags in the conventional manner I'm not sure committing non-trivial code changes to /tags/ is a conventional manner. Conventional use of /tags/ is placing a copy there.
sebb>It is to allow the docs for the current release to be corrected after What is the purpose of updating documentation for past releases? What's the purpose of having doc-v2_3_3 branch? sebb> Same as above; so the published Javadocs agree with the latest release. Javadocs are much more convenient to read from Maven Central artifacts and/or from http://javadoc.io/doc/org.apache.jmeter/ApacheJMeter_java/5.1 . IDE can automatically download -javadocs jars and display it it accordingly. I'm sure we don't really want to place autogenerated files like *.class, *.jar, *.tar.gz, and *javadoc* under source control. sebb> In what way? It's very clear from the SVN tags. They are not more than a subfolder, so there might be changes that are missing in the "mainline". Here's an example of a code change in a "tag" folder: oups! Revert https://svn.apache.org/repos/asf/jmeter/tags/v2_8_RC2@1394979 Then there's this commit 1342362: Tag for pre-release https://svn.apache.org/repos/asf/jmeter/tags/v2_7_RC2@1342362 http://svn.apache.org/viewvc?view=revision&revision=1342362 The problem with 1342362 is it did edit multiple files (not just the usual version in build.xml), and it is absolutely not clear if those change was left on that "tag" only. The "problem" with SVN tags (at least with the way JMeter uses them) is the history never continues from a tag. It just keeps hanging as a side branch. At the end of the day, SVN does not distinguish between tag and branch, so one can silently put code changes into a tag. In other words, I would prefer the following history: 1. Initial commit 2. hack, the version is 1.0-SNAPSHOT 3. Set version to 1.0. Tag v1.0 points to this commit 4. Set version to 1.1-SNAPSHOT. 5. hack, the version is still 1.1-SNAPSHOT, <-- master branch points to here .. creating RC ... 6. Set version to 1.1. create tag v1.1_RC1. "master" still points to commit #5 If vote succeeds, then master branch is promoted to commit 6. In other words, master should point to exactly the same commit which was voted on. At the end of the day, the primary goal of Apache is to release source artifacts. Binaries are for convenience only. sebb>In what way? It's very clear from the SVN tags For instance, can you tell which version was affected by commit 1378856? Which version (or RC) includes the commit? Reduce log level (duplicates message from JMeterThread) https://svn.apache.org/repos/asf/jmeter/trunk@1378856 If tags are placed (like my script does) at the mainline branch (in other words, if tags point to commits of "trunk" branch), then it is trivial (see "follows" and "precedes" in the attached 1378856_vs_tags.png) sebb>It is important that the online docs agree with the current release. If you mean "we don't want to publish snapshot" features to the site while we want to fix site typos, then I think the approach there is to keep release branches. Then if we need to update the site, we put relevant updates to the release branch (to the relevant xdocs files), build the docs and publish it. It is effectively the same thing as if we would like to release 4.0.1 with a code change. We could fork a branch, put some changes, and release it. Nevertheless I would prefer linear histories rather than complicated merge mess that happens with current tags and docs branches. Vladimir
