Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Tag future releases #31

Closed
hasufell opened this Issue · 18 comments

4 participants

Julian Ospald Lee Thomason Steven Peters Octavio Alvarez
Julian Ospald

Plz tag future releases. That's a nice convenience.

Lee Thomason
Owner

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

Steven Peters

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/homebrew#23381

Lee Thomason
Owner

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.

Steven Peters

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.

Octavio Alvarez

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.

Lee Thomason
Owner

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

Julian Ospald

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

Lee Thomason
Owner

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?

Lee Thomason leethomason reopened this
Lee Thomason
Owner

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.

Julian Ospald

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

Lee Thomason
Owner

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

Julian Ospald

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.

Octavio Alvarez

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.

Julian Ospald

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
Barbatos/ioq3-for-UrbanTerror-4#18

Lee Thomason
Owner

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.

Lee Thomason
Owner

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

Octavio Alvarez

Very much appreciated.

Steven Peters scpeters referenced this issue in Homebrew/homebrew
Closed

tinyxml2 2.0.2: new formula #27622

Steven Peters

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.