sebb> Given that SVN history for tags/testhead We have agreed that we don't need the tags, so let's just drop them and close the discussion. Note: I don't care if the tags will be removed from SVN or not.
sebb> No, it's just the reverse, because 5.2-SNAPSHOT is later than sebb> 5.1-SNAPSHOT so it 'hides' the later builds which are tagged sebb> 5.1-SNAPSHOT. Suppose a client is using 5.1-SNAPSHOT version: <dependency>...<artifactId>ApacheJMeter_core</artifactId><version>5.1-SNAPSHOT</version> Then 5.2-SNAPSHOT won't 'hide' it or whatever. The client will use 5.1-SNAPSHOT no matter whatever other versions (snapshot or non-snapshot) are released. What do you mean by 'hides'? > > 5.1-SNAPSHOT > > 5.1-SNAPSHOT > > 5.2 <- this commit is tagged with v5.2 > > 5.3-SNAPSHOT > > 5.3-SNAPSHOT > sebb> The above is wrong - what happened to 5.2-SNAPSHOT? For instance: it was agreed to release the version as 5.2 even though snapshot was named 5.1-SNAPSHOT. Technically speaking I intended to list 5.2-SNAPSHOT instead of 5.1-SNAPSHOT. However both histories are perfectly fine even though 5.1-SNAPSHOT->5.2 is slightly confusing. My point is at some (single!) point in time master branch should have a release version. sebb>At this point master has a release version, which is a no-no as sebb>already explained. You have never explained why it is wrong to have a single commit with a release version in a master branch. Would you please elaborate? sebb> It's documented on the Wiki My point is docs-x.y violates POLA and release-x.y does not. Vladimir
