On Tue, 26 Feb 2019 at 05:52, Vladimir Sitnikov
<[email protected]> wrote:
>
> 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.

We should clear up SVN before doing any conversion to Git.

> 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'?

A person looking at the repo will see that there is 5.2-SNAPSHOT and
naturally assume it is more recent than 5.1-SNAPSHOT.

> > > 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.

AFAIK, we never do that; 5.2 is released from 5.2-SNAPSHOT

> Technically speaking I intended to list 5.2-SNAPSHOT instead of 5.1-SNAPSHOT.

Understood.

> However both histories are perfectly fine even though
> 5.1-SNAPSHOT->5.2 is slightly confusing.

OK, except I disagree that trunk/master should ever be a release version.

> My point is at some (single!) point in time master branch should have
> a release version.

This is where we disagree - it should never have a release version
otherwise there are issues with CI and potential confusion over what
is the release.

> 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?

I already explained this several times: any CI builds create what
looks like a release version.

Also, if anyone exports the master at that point, it appears to be a
release, and local builds will generate what appear to be releases
from the version.

Violates POLA.

> sebb> It's documented on the Wiki
>
> My point is docs-x.y violates POLA and release-x.y does not.

I disagree, because docs-x.y is not a release.
It is the docs for the release-x.y, so it should be named something like

docs-for-release-x.y

in order to be obvious.


> Vladimir

Reply via email to