Tag future releases

[leethomason]

Tag future releases

[leethomason]

Good idea - need to build that into the setversion.py script, however. Else I'll forget every time. Marking as enhancement.

[scpeters]

We would like to get tinyxml2 into the master homebrew repository, but they need tagged releases. Could we just go back and tag some commits where you increment the version number?

Homebrew/legacy-homebrew#23381

[leethomason]

This one is hanging over my head. I actually mean to pull out the version numbers - they aren't tested, and it isn't clear they are correct. The other option would be to just have one version number that is incremented with every checkin.

I'd appreciate thoughts on a useful-for-you version system that doesn't require me to test for binary compatibility all the time.

[scpeters]

The people who want tagging are probably wanting to release the code through debian/ubuntu or home-brew. Three aspects stand out to me:

1. tags with sequential numbering are convenient for distinguishing the relative age of different snapshots of the code base (impossible to do by visually inspecting changeset hashes). it also helps with package management
2. identifying stable versions of the software: typically code is tagged after it has been tested for a while and appears to be reasonably stable.
3. indicating API / ABI stability through version numbering

I think the first two are most important to me, and would be useful even if you don't have any API/ABI testing in place.

[alvarezp]

It's important to know whether API compatibility breaks or not. The best possible version scheme is: major.minor.build.

If you want to change the API or make a backwards-incompatible change, bump the major on your next release.

If you want to change behavior in a backwards-compatible way and without changing the API, bump the minor version.

For simple bug fixes that don't affect behavior or API, just bump the build number.

This help us know. For example, at this moment I don't know how safe is to update TinyXML-2, and whether it will break dependent applications.

[leethomason]

That's reasonable. I'll add notes to the code. (And not tag - I don't want to deal with both systems.)

[hasufell]

Tinyxml2 has effectively no release at all. That leads to packagers picking random commits for a snapshot without any good idea about it. I don't understand how notes in the code do improve that situation.

http://git-scm.com/book/en/Git-Basics-Tagging
https://github.com/blog/1547-release-your-software

[leethomason]

TinyXML-2 isn't intended to be packaged - that's a level of care paid to the API surface that I generally don't attempt. I'm trying to help out for those that want dll/packaging to work, but it's on the edge of the scope of the project.

All pushes to github pass the test suite.

I'm open to pulling out the versions in the source files, and switching to tagging, but having both is plainly a recipe for mistakes.

Thoughts?

[leethomason]

Which - to be clear - I'm fine with. I don't particularly like having the version in the header. I don't think that's actually adding real info either. I'm just checking that pulling versioning from the header to git is okay for people.

[hasufell]

Intended or not, it is already packaged in major distributions.

debian: https://packages.debian.org/sid/libtinyxml2-0.0.0 (here the versioning seems wrong, so there is already confusion)

gentoo: http://packages.gentoo.org/package/dev-libs/tinyxml2

fedora: https://apps.fedoraproject.org/packages/tinyxml2

[leethomason]

Yeah...the debian thing is TinyXML-1, They changed the version on there own. Grr. Again, I'm not trying to stop this, it just isn't the focus. So what the minimal, reasonable approach? (Git or header? Git and header?)

[hasufell]

Which - to be clear - I'm fine with. I don't particularly like having the version in the header. I don't think that's actually adding real info either. I'm just checking that pulling versioning from the header to git is okay for people.

Hm, theoretically some people could use the header versioning for their own code conditionals. The easiest thing could be a commit hook that checks existent git tags against the version in the header (with some grep/sed magic) and creates and pushes a new tag if there is no match.

[alvarezp]

Tags would be a lot better. For starters, Github would actually convert them to downloadable releases.

There are two reasons distributions --Debian, at least-- prefer to pack a library (as opposed to embed in apps). One is that multiple copies of the same code is avoided, reducing oversall distribution size, reducing bandwidth and system memory footprint.

The other one is that if a vulnerability is found, fixing applications would require patching every application and unpatching when upstream adopts a newer version of the library (which may or may not happen). With numbered releases and knowing what version fixes it and having it packed separately, it's just a matter of repackaging the library and relinking/recompiling applications. The latter can sometimes be done automatically by the distribution infrastructure. See section 4.13:

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

It's easy to "take care to the API surface" if you use Git branches: have a "master" branch where you can do whatever you want. Have a "2.x" where you carefully manage behavior only and "2.0.x" branch where you only stabilize, no behavior or API changes. It's easy to cherry-pick commits between branches.

[hasufell]

There are two reasons distributions --Debian, at least-- prefer to pack a library (as opposed to embed in apps).

there are a lot more:
https://blog.flameeyes.eu/2009/01/bundling-libraries-for-despair-and-insecurity
FrozenSand/ioq3-for-UrbanTerror-4#18

[leethomason]

Okay - how about this for a plan. There is already a python script to set the version. I can play around with expanding it to:

• set the version
• build
• commit
• tag

Which would, I think, meet everyone's needs. Then the version is in sync, in the header, in git, and has meaning to major/minor/build. And after I get the script running, it won't be annoying me. I'll take a look at getting that practically working.

[leethomason]

Done. There is now tags, releases, and versioning.

[alvarezp]

Very much appreciated.

[scpeters]

Thank you very much. I have just submitted a formula to homebrew for tinyxml2.