Mailinglist Archive: yast-devel (61 mails)

< Previous Next >
Re: [yast-devel] RFC: yast-rake task for release
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@xxxxxxx> wrote:

Dne 29.9.2014 v 15:43 Josef Reidinger napsal(a):
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

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:

Wed Oct 1 09:15:23 UTC 2014 - myself@xxxxxxx

- █
- 3.1.104
# If this comment stays or if the whole entry is removed, "rake release" will

Mon Sep 29 22:14:49 UTC 2014 - user@xxxxxxxx

- bnc#111111
- do not write LOLADDR="00:00:00:00:00:00"
- 3.1.103


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

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
we should use these tags:


or if the code is shared:

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

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.


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

Thanks for starting the discussion!

Martin Vidner, Cloud & Systems Management Team

Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
< Previous Next >
This Thread
  • No further messages