git describe gives incorrect output

[ejgallego]

In main:

$ git describe --tags 
2.8.0-779-g358ff6392

That's annoying if one wants to use dune --version with dev builds.

I'd suggest tagging 3.0+alpha etc... when branching. In this case, we'd miss a 2.9+alpha and 3.0+alpha tag.

[ghost]

The thing is that we often synchronise the bugfix between the branches and main. So if we were tagging 2.9+alpha when branching 2.9, then something that would morally be 2.9.4 + dev towards 3.0 might be reported as 2.9+alpha, which doesn't seem right either. I feel like if we want to be accurate there, we have to maintain the version explicitly somewhere in a file.

[jberdine]

Would it help if there were a way to use something similar to ~ in version? I'm thinking that since opam and other tools consider 3.1~4 to be below 3.1, then if branching of development towards 3.1 the commit could be git tagged with 3.1~, and then git describe would be able to produce a version with the correct interpretation. There is a catch that git does not allow ~ in tags. But perhaps opam and friends could be extended to treat some other char that git does allow as ~ is now.

Related: #3856

[ghost]

I suppose, but why? It feels like a lot of effort to stick to git describe when we could achieve the same goal by simpler means.

[ejgallego]

The thing is that we often synchronise the bugfix between the branches and main. So if we were tagging 2.9+alpha when branching 2.9, then something that would morally be 2.9.4 + dev towards 3.0 might be reported as 2.9+alpha, which doesn't seem right either. I feel like if we want to be accurate there, we have to maintain the version explicitly somewhere in a file.

Oh, in that case we would also tag 2.9.4 too, so it would work fine, right? The 2.9+alpha would only be used until the tag of the rc or release.

Sorry I wasn't clear, you tag the alpha version when you branch for the stable, but you tag the next version. So in this case, the first commit of 3.0, would be tagged 3.0+alpha, and similarly the first commit of 2.9 [after the 2.8 branching] would have been tagged 2.9+alpha.

Using a file is also very fine I think.

[ghost]

I was splitting hair TBH. I'm usually not a big fan of extra tags as these just accumulate and I find a big list of tags with a lot of alphas and betas a bit messy, but it's not a good argument.

@jberdine, thinking about you said again, we could also teach opam about the concept of "alpha" and "beta" rather than introduce new character meanings. At the end of the day, alpha and beta versions are widely used concepts.

[ejgallego]

I was splitting hair TBH. I'm usually not a big fan of extra tags as these just accumulate and I find a big list of tags with a lot of alphas and betas a bit messy, but it's not a good argument.

I also don't like noise in tags, but that's one extra tag for each major release so I can live with it.

[ejgallego]

After reviewing the git history, I propose:

• tag 9bf450e 2.9+alpha
• tag 3cb82b3 3.0+alpha

[ghost]

These commits seem good to me.

[ejgallego]

Fixed, thanks to all. git describe now outputs for main : 3.0+alpha-794-gfb3c71d29