On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > On Čt, 2015-11-19 at 20:59 +0000, Sérgio Basto wrote:
> > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > > > "SB" == Sérgio Basto <ser...@serjux.com> writes:
> > > > > 
> > > > > SB> When we fix the .spec and don't change the source, we
> > > > > bump
> > > > > rightmost
> > > > > SB> version, when we change the source, we bump the left
> > > > > version,
> > > > > so
> > > > > we
> > > > > SB> can distinguish when we update the source and when we
> > > > > updated
> > > > > the
> > > > > SB> .spec, this contrast for me is important.
> > > > > 
> > > > > For me, the simple rule that a Release: tag less than 1
> > > > > implies
> > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > implies
> > > > > a
> > > > > post-release package, is important.  So far the proponents of
> > > > > this
> > > > > change haven't shown what things would actually look like
> > > > > after
> > > > > this
> > > > > change, so it's hard for me to come up with a reason to
> > > > > change my
> > > > > opinion.
> > > > 
> > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > because :
> > > > 
> > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > 
> > > Nope, 1>"b" in rpm version compare.
> 
> Even so, we shouldn't depend on upstream preserving sorting order in
> their pre-release suffixes. Numerical sorting is always monotonous.
> 
> > If so, we could begging numeration with 0 for pre-release: 
> > 
> > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > foo-
> > 0.2.a.1 
> 
> I don't understand why you want to introduce another level of
> numbering.
> What's wrong with the current guideline?

I'd like improve for cases that upstream doesn't make a release and
the package stays forever in a pre-release, this happens a lot with
old projects that are half dead upstream, instead of have just one
counter, we have two counters, one when upstream change the source
other when we rebuild the package, it will be better readable, to
understand if the upstream had updates or not.

Best regards,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to