On Tue, 26 Feb 2019 at 09:53, Vladimir Sitnikov <[email protected]> wrote: > > sebb> We should clear up SVN before doing any conversion to Git. > > Which cleanup do you mean?
Deleting any unnecessary tags; I've already done that for the test tags. > 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? I've already answered this many times. > 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. If master changes directly from 5.1-SNAPSHOT to 5.2-SNAPSHOT, then I agree there is no problem. But my reading of what you wrote was that master would be set to 5.1 at some point, i.e. it was not an atomic change of snapshot version. > 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. But we can prevent that build from having a release version. > 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". That's OK, because it is using the correct source for the build. > 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. Because a tag is known to be a specific version and tags are not the default download from a repo. > 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. But we don't want any such branches to have any source code updates. The point about the docs branch is that it is only intended for doc updates. However it needs more than just the xdocs files in order to build. > The documentation artifacts would be put to a separate repository > (jmeter-site). The xdocs files which are used to build the site are also used to build the Help files. We don't want duplicate copies in different repos. As already noted, I think it's going to be tricky to separate the two. > 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. It has to contain more than the documentation, as it needs various support files to build the docs And it needs the sources if it proved necessary to rebuild the Javadocs > Vladimir
