Ad. Zbyszek:
> What about doing <name>-<version>-<dist>.<commits-since-version-bump>?
> This means that upgrade path not affected by the number of commits or
> builds in the older release.
I was thinking how to properly implement this into rpkg-util and then
finally, it clicked for me.
First, I added the prefix parameter for git_release macro (below
git_dir_release is used instead, which is the recommended form). Hence
now, one can specify:
Release: {{{ git_dir_release prefix="0%{?dist}" }}}
which would produce release strings like:
0.fc32.1
0.fc32.2
0.fc32.3
for each tag in f32 branch. The leading zero is not used here for
anything but without it, we would get NVRs like somepkg-1.0-.fc32.1 -
i.e. dash would be followed by immediate dot, which is not actually
invalid but it is strange.
Then it came to me that instead of %{dist} we can simply use branch
name and hence (finally) drop "c" from .fcXY:
Release: {{{ git_dir_release prefix="$GIT_BRANCH" }}}
("$GIT_BRANCH" is a macro variable that gives you name of the
currently checked out branch)
This will not work for cases when people put some special stuff into
%{dist} like Nicolas showed:
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-release.spec#_488
but it would work for simple cases and fallback would be possible.
Finally, one can just alias `git_dir_release prefix="$GIT_BRANCH"`
with `git_dir_release_branched`
(https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_464)
and hence get the following:
Release: {{{ git_dir_release_branched }}}
which will be bumping release with respect to the latest tag on the
current branch as well as the commits stacked on top of that tag (it
will be also bumping release for uncommitted work if your working tree
is dirty but i don't want to show it here now because NVRs are then
quite long).
I've prepared a test project for this new macro:
https://pagure.io/hello_rpkg_release. You need the latest "rpkg" and
"rpkg-macros" from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ for it to
work. But I also just dumped the results here:
https://pagure.io/hello_rpkg_release/tree/result . You can see what
NVRs are generated (by `rpkg nvr` command) at each particular point
for the given branch (i.e. hello_rpkg_release-1.14.0-f32.2 for the
second tagged commit in f32 branch) -- they are written down after the
"-->" arrow. I mention there three NVRs in total:
hello_rpkg_release-1.14.0-master.1 (the first tagged commit master branch
hello_rpkg_release-1.14.0-f32.2 (the second tagged commit in the f32 branch)
hello_rpkg_release-1.14.0-f31.1.git.1.34684da9 (untagged commit on
top of the first tagged commit in the f31 branch)
Any feedback welcome.
On Mon, 2 Mar 2020 at 14:51, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Mon, Mar 2, 2020 at 8:46 AM clime <clime@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > If you don’t keep things decentralized you’ll be in a word of pain when
> > > the scm or buildsys needs to be changed for another implementation (not
> > > to mention, that’s not a good way to collaborate with other distros).
> > > That will happen eventually. Web apps are not eternal.
> >
> > Full decentralization likely means that everyone has its own git repo
> > and we can only sync by mailing list. I think src.fp.o is a good point
> > where things can be done and where we can agree on what the packages
> > that Fedora produce are (meaning we need a canonical source of package
> > sources, otherwise it would be more complex to put a distribution
> > together).
> >
>
> This is not true. Pagure accepts PRs from arbitrary Git servers just
> fine via the remote PR feature, so we do support decentralized
> workflows without resorting to sending patches via email or Bugzilla.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
