regular tagged releases

[0xaf1f]

I see that you've tagged the first release, but it looks (based on commit messages and twitter posts) like you've made one other major release and another bug-fix release since then. It would be helpful if you could continue to tag the relevant commits so that it is clear which snapshot we should be using and which are just intermediate states.

Many thanks and regards Afif

[thegenemyers]

Hi Afif, Basically I am not ever committing interim developments. So while I can tag occasional versions as a form of "milestone", one should always just get the most recent commit and that should work with your current data sets, .db's, .ovl-files, etc. There have only been a couple of instances where a database or other object you might be working with became incompatible with the updated code base. In both instances those were clearly documented, when they occurred, and I provided update programs. I apologize that I may be so "old-school" that I am not following git conventions. Perhaps you can educate me -- when would you like to see new tags?

[0xaf1f]

Hello and thanks for your reply. My primary reason for requesting the tags is that I have packaged these programs for Debian and our version tracker heavily relies on them to notify of new releases.

If you'd still prefer to continue as you are now, I suppose I can just subscribe to your repositories and update the packages whenever the git activity resurges and I see that it stabilizes. The tags are still preferable because they would be your indication of upgrade urgency and compatibility in a concise form, but I can work around whatever you choose to do.

[cdunn2001]

For the record, I like your "old-school" ways, Herr Myers.

@afif-elghraoui, you can download a tarball based on a commit too, so you do not actually need a tag. If you want the latest, you can download based on a branch. Gene has been very careful about backward-compatibility, so I do not think you have anything to worry about.

I maintain another package which is packaged for Debian, and we do tag that. We even sign it. That is a different situation, since it is a library and we sometimes are forced to make incompatible changes.

[0xaf1f]

On السبت 5 آذار 2016 09:27, Christopher Dunn wrote:

@afif-elghraoui https://github.com/afif-elghraoui, you can download a tarball based on a commit too, so you do not actually need a tag. If you want the latest, you can download based on a branch.

Yes, I'm aware of that. Unfortunately, that means the Debian/Ubuntu packaged versions start looking like 1.0+20151214-1 and that new versions get packaged when I happen to notice new activity on github (uscan(1) can't effectively monitor git commit logs)

I maintain another package which is packaged for Debian, and we /do/ tag that. We even sign it. That is a different situation, since it is a library and we sometimes are forced to make incompatible changes.

This doesn't have much to do with backwards-compatibility. If releases aren't tagged, we have trouble finding out when there are new versions to package. Signed releases are nice for a totally different reason, but that isn't related to backwards-compatibility, either.

[tillea]

Hi I admit I consider relying on Git commits not old school at all. Versioned tarballs existed before Git (and several other version control systems). Since the Debian tool uscan is relying on the old school versioned tarball downloads which are created at Github once a commit gets a tag it would be really helpful if you could do the tagging. The situation is simple: If you are interested that we are always distributing the latest and greatest daligner code to Debian/Ubuntu users you set the tags - if not your mileage might vary since we might not notice every commit. Kind regards, Andreas.