Version tag specification

[robert7]

Version tag specification

[robert7]

Hi.
basically you have it right. But I will describe the "build pipeline" in a wiki page and post here a link, as it seems it is unclear for more people.

"v2.0.2" is the last "old" stable release from upstream - but this is quite old, so better not use it for new packaging.
But the upcoming release will have same format, so your command is OK.

v2.1.0 is already very close to a "stable release".. there should be a "v2.1.0" release soon.

..so I create the wiki page with details and post it here.

[HaleTom]

Thanks!

I just noticed:

v2.1.0-beta-1 has 2 - but v2.1.0-alpha10 only has one.

You'll be going with two?

[robert7]

So I created a wiki page with description: Releases versions, build pipeline, branches, tags...
Pls look at it if it answer all question. This is first version - I will improve it later.

There were 2 hyphens used pre-release tags e.g. in "v2.1.0-beta-1", but I would in the future only use one hyphen. So it will be like "v2.1.0-beta1". Version inside application and in the "debian/changelog" file is without the prefix "v". The prefix "v" follows the naming convention of tags from upstream.

Further you can distinguish the "pre release" from "release" according to semantic versioning by checking of the presence of the hyphen character. This is better then filtering out "alpha and beta" words. So you may adjust the "grep" examples. I copied them into the wiki page - i'll adjust them later,

I did not understand the question 5:

"Will unannotated git tags continue to describe only full releases?"

Basically "v" prefix means release. Exceptional/special tags are "continuous-develop" (tip of the development branch) and "continuous" (tip of the master branch). Those are moved after each merge and created as part of the Travis CI pipeline.

[robert7]

So tags belonging to "stable releases" are those with prefix "v" and which don't contain hyphen character.

Example of finding latest release:

$ git tag --list | grep '^v' | grep -v '-' | tail -n1
v2.0.2

[HaleTom]

Cheers for specifying all that! Nice one.

man git-tag says:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore
lightweight tags by default.

% git describe --abbrev=0    
v2.0.2

Will this continue when you make your first release?

Thinking of the future, what is the process for preparing for a release?

• Is there a new feature freeze? If so, is there a period of time or number of develop releases?
• Does the naming reflect intent-to-release, eg -rc#? (Some packagers may appreciate this, as it's likely to be more stable than a -beta.)

I look forward to a release soon - you've done bunches of great work. Congratulations and thank you.

[HaleTom]

BTW, your quoting of '-' doesn't actually do anything. I think what you're looking for is:

git tag --list | grep '^v' | grep -v -- - | tail -n1

But given git describe --abbrev=0 this may be moot after all.

[robert7]

BTW, your quoting of '-' doesn't actually do anything.

Funny. I tried and it seems both return the same output (at least on my system). But anyway. Just filter out the names with hyphen.

Annotated tags are meant for release while lightweight tags are meant for private or temporary object

OK. Actually I did not know that. But it seems reasonable. So I can follow that (i'll update the wiki page later).

Thinking of the future, what is the process for preparing for a release?
Is there a new feature freeze?

Ok. The project is quite small. So far with a "team" consisting of "me" :) .. so I didn't want to create "over complicated release process" .. I did no "rc" releases. But basically the last "beta3" is already a kind of "rc1"... Now the plan is to fix few more minor bugs (I know about few), then do a release. So now its already a kind of feature freeze.

[HaleTom]

Awesome! :)

I'll be making 2 "build-from-source" packages:

• The latest v* tag, (after #31 is resolved)
• A "release" version (when a new non-hyphenated version is released)

I may also look at making "binary" packages by pulling apart the AppImage for faster package installs (since the build takes some time on my laptop). The bonus of this over the AppImage would be access to documentation.

[robert7]

I'll be making 2 "build-from-source" package

Great!
I don't have much time now, but I will look at the issues you created more closely during next week.

[robert7]

I recreated the tags I created for v2.1 beta versions. I know, this is probably not a "best practice", but its "one time cleanup" and it will make easier in the future to stick with the declared naming/annotation conventions...

1. All release tags have "annotation"
2. Pre-releases contain "hyphen", Release don't contain hyphen
3. Non-release tags (like "continuous") don't have annotation
4. "2 hyphens" in version tag are not used anymore
5. Next release tag will be "v2.1.0-rc1"

I'm not sure, if the tags in your repository clone will update with simple "pull", you may need to do a fresh clone.

It now looks like:

[HaleTom]

Nice alignment.

For other packagers, the command to get the latest versioned tag is:

git -c 'versionsort.suffix=-' ls-remote -t --exit-code --refs --sort=-v:refname \
  https://github.com/robert7/nixnote2.git 'v*' \
  | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\/tags\/(.+)/\1/g'

[HaleTom]

FYI, I dug deeper into the Arch packaging guidelines, and -git packages need to be be built from the HEAD of the default branch of the repository.

(The implied assumption is that the default branch is the "use-this-release" branch)

[robert7]

..packages need to be be built from the HEAD of the default branch of the repository.

So this would be the master branch. this is actually what I would also recommend.
This is the "latest stable build" (this is also mirrored by the current PPA build (nixnote-stable) and by the "stable AppImage" build - https://github.com/robert7/nixnote2/releases/tag/continuous