On Sun, 24 Feb 2019 at 16:09, Vladimir Sitnikov <[email protected]> wrote: > > 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.
Huh? AFAICT there were no changes to tags once created. Have you any counter-examples? > 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? Not sure what you mean. The branch is created for the maintaining current release. Of course at some point that becomes a previous release, but SVN branches are cheap so there's no particular need to drop them. And if any changes were made, it would be good to review these before deletion to ensure that the trunk docs have been corrected if necessary. > What's the purpose of having doc-v2_3_3 branch? Not sure what you are asking here. > 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. A lot of projects have Javadocs on the website. > I'm sure we don't really want to place autogenerated files like *.class, > *.jar, *.tar.gz, and *javadoc* under source control. The Javadocs are are only in SVN to put them on the website. > 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. AFAICT it did not *change* files (apart from build.xml); it copied them from trunk. I think you are misreading the commit details. > 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. This is not a problem in the way JMeter uses tags. It is how tags are supposed to be used in SVN. Create once and never change them. > At the end of the day, SVN does not distinguish between tag and branch, so > one can silently put code changes into a tag. Not silently, because there will be a commit message. But yes, tags are not immutable - that is why vote mails include the revision. Unfortunately SVN does not allow tags to be marked read-only, so it has to be done by convention. This is the way it has always been for ASF projects I have worked on. So this is not a JMeter issue. > In other words, I would prefer the following history: Are your referring to SVN or Git here? > 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 It's not clear exactly what commits are being made above. It looks as though master (do you mean trunk?) may be changed to the new version in step 3 before the release vote completes. This is not acceptable: as explained previously, it causes problems for CI builds. > 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. I agree that the release tag should agree with the tag that was voted on. This is done in JMeter by copying the RC tag to the GA tag. Other projects may do this differently, e.g. I think Tomcat uses a tag without an RC suffix. If the vote fails, the version is bumped for the next vote, i.e. the failed version number is not used for a release. But the end result is the same: the SVN GA tag can be tied directly to the release vote. > 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
