sebb> We should clear up SVN before doing any conversion to Git. Which cleanup do you mean?
sebb> A person looking at the repo will see that there is 5.2-SNAPSHOT and sebb> naturally assume it is more recent than 5.1-SNAPSHOT. That is true, however it does not harm much since exactly the same person would check website as well. On the other hand, automatic build that fetches 5.1-SNAPSHOT would never be confused by 5.2-SNAPSHOT. sebb>otherwise there are issues with CI and potential confusion over what sebb>is the release Which CI issues? Can you please pin-point at least a single one? master branch is advanced *atomically* from 5.1-SNAPSHOT to 5.2-SNAPSHOT even though there's 5.1 in-between. What CI issues could happen in that case? I truly don't see. sebb>and local builds will generate what appear to be releases sebb>from the version. In ideal world, builds are 100% reproducible. In other words, one should be able to reproduce the build by performing exactly the same steps. If a person manually checks out master branch at random, commits and deploys to whatever repository, we can't really prevent that. Can you please explain how SVN tags prevents that? A person might checkout SVN tag, perform build which will generate what "appear to be release". Even though "release versions" are placed in SVN tags, one can export that tag and "local builds will generate what appear to be releases". I don't really see why you think placing release versions at tags only somehow magically resolves the issue. Vladimir> My point is docs-x.y violates POLA and release-x.y does not. sebb>I disagree, because docs-x.y is not a release. I see. You don't see the full picture then. I suggest we have release-x.y branches that would be *release* branches with source code. The documentation artifacts would be put to a separate repository (jmeter-site). That would make docs-x.y branches obsolete and it would make source code easier to follow. sebb>docs-for-release-x.y PS. "docs-for-release-x.y" name would still violate POLA if it contains more than the documentation. Vladimir
