On Tue, 3 Mar 2020 at 00:28, clime <clime@xxxxxxxxxxxxxxxxx> 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-release.spec#_488
> 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@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
