On Mon, 25 Feb 2019 at 16:33, Vladimir Sitnikov <[email protected]> wrote: > > sebb> AFAICT there were no changes to tags once created. > sebb> Have you any counter-examples? > > sebb, please explain this: > http://svn.apache.org/viewvc/jmeter/tags/v2_8_RC2/doap_JMeter.rdf?r1=1394979&r2=1394978&pathrev=1394979 > > I read that as a commit that modifies doap_JMeter.rdf file in a > tags/v2_8_RC2 "branch".
Yes, that is a mistake. It should not have happened. As already explained, it is precisely because it's not possible to make tags truly immutable that the vote mails contain the tag version. > Apparently tags are very mutable species in SVN. Yes, as I already wrote: <quote> 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. </quote> > sebb>This is not acceptable: as explained previously, it causes problems > sebb>for CI builds. > > Do you mean SVN somehow magically prevents that issue? No, I mean that the trunk/master repo should not be updated to the new snapshot version until the release vote has succeeded. > I value your passion to the details, however please note that JMeter SVN > trunk causes CI issues right now. > Current build.xml says "5.1-SNAPSHOT", and we all know 5.1 has already been > released. Yes, that needs to be updated, it should have been done at the time of release. However this is a minor issue. It will be corrected in the snapshot repo as soon as the version is updated to 5.2-SNAPSHOT. By contrast, if the trunk is updated to 5.2-SNAPSHOT before the release vote, and the release fails, CI builds won't be replaced when the version is backdated to 5.1-SNAPSHOT. The 5.2-SNAPSHOT builds will hang around unless manually deleted; this is confusing because they are older than the ongoing 5.1-SNAPSHOT builds. That is why the version is changed in the tag only, and trunk is only updated upon release. > Vladimir
