On Tue, 3 Mar 2020 at 00:28, clime <clime(a)fedoraproject.org> wrote:
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
Actually, that wouldn't work because prefix needs to be static, not
dependent on rpm macros (we would be searching for tags that contain
literally '0%{?dist}' in the last release part after the dash when
generating the current release based on past tag names). Only the
below versions that depend just on Git would work. I was hoping I can
get a fallback for cases like Nicolas or the ruby packages have but
that doesn't seem to be possible (at least to me at the moment).
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-re...
but it would work for simple cases and fallback would be possible.
See above, regrettably.
>
> 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(a)gmail.com> wrote:
> >
> > On Mon, Mar 2, 2020 at 8:46 AM clime <clime(a)fedoraproject.org> wrote:
> > >
> > > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> > > <devel(a)lists.fedoraproject.org> 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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@lists.fedoraproject.org