On Tue, Sep 30, 2014 at 09:37:33AM +0200, Josef Reidinger wrote:

On Tue, 30 Sep 2014 09:29:53 +0200 Ladislav Slezak <lslezak@suse.cz> wrote:

...

Dne 29.9.2014 v 15:43 Josef Reidinger napsal(a):

...

Hi, maybe some of you still missing old script for tagging git with released version numbers. Or sometimes forgot to update spec file when changing changes file ( like me ). So I propose to add new yast-rake task "release". What it will do:

1) call "osc vc" and stop if user do not specify changes 2) call "rake version:bump" to increase version

I usually add a version number into the changes when releasing so it would be nice to add it automatically, so the workflow would be like this:

1) "rake version:bump" 2) add "- #{version}" to *.changes at the top (maybe grep if it is not already there)

Yes, I also want this.

This is not so easy as next osc vc will create new entry so version tag will not be present there, only if I create such entry with `osc vc -m` and then `call osc -e` but problem can be how to allow easy cancel of operation in such case?

It is a pity that -m and -e cannot be used together, but we can simply `osc vc -m` with a template text which includes the version and a helpful comment, and then just call the editor on the file, even placing the cursor after the dash: --8<-- ------------------------------------------------------------------- Wed Oct 1 09:15:23 UTC 2014 - myself@suse.cz - █ - 3.1.104 # If this comment stays or if the whole entry is removed, "rake release" will stop ------------------------------------------------------------------- Mon Sep 29 22:14:49 UTC 2014 - user@suse.com - bnc#111111 - do not write LOLADDR="00:00:00:00:00:00" - 3.1.103 ------------------------------------------------------------------- ... --8<--

...

3) run "osc vc" (BTW what is the difference to "buildvc" which I'm using?)

I think there is no difference, just source of email address.

...

...

3) create git commit with message "release #{version}" 4) tag this commit with version number like "3.1.125"

There might be a collision when releasing the same version for SLE and openSUSE.

I think we do not allow it. My opinion is that we should act like upstream project and if we start maintaining some branch, then create unique versioning. ( I think we add .<num> to version when we start such long maintenance branch.

This needs more thought. Another way is leaving the tagging to Jenkins once the build succeeds.

...

According to https://en.opensuse.org/openSUSE:YaST_SVN_to_GIT we should use these tags:

openSUSE-${VER} SLE-${SLE_VER}

or if the code is shared: Code-${SLE_VER}

Is that still valid/sufficient? Or should we use a different schema?

IMO this is outdated, plain numbers should do as tags

For me package of given version should be same for opensuse and also SLE.

...

...

It do not push change. It also require manual "push --tags" as I want to have the very last break, which allows me to check it again before I push it.

Yes, I'd also prefer manual push, but optional "--push" switch would be nice.

yes, it is possible to have it.

Josef

...

...

What do you think about it? I welcome any comments or suggestions before I implement it.

Thanks for starting the discussion!

+1 -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu