Tomas Volf <[email protected]> writes:
So, the question is, do we want some rules for the naming and
versioning
of the packages (e.g., $pkg is any *released* version, and
$pkg-next is
*any* version, often newer, possibly git snapshot or a release
candidate)? Or do you feel this would be governance overreach,
it
should stay strictly up to the packagers and we should just
document
that users who do not want release candidates should just always
pin
versions of everything?
When a package is based on an untagged git snapshot, I think it's
important to consider the extent of the changes since the last tag
and
the reasons for pinning a package at that revision.
A snapshot might represent a large set of bleeding-edge changes,
and it
sounds like there's some consensus that a `-next` suffix is
warranted in
this case. But oftentimes I seem a package use a git snapshot
because
upstream contains a small-but-necessary compatibility fix. One
might
ask, if this fix is reliable, shouldn't upstream have cut a new
release?
Probably, but as others have mentioned, upstreams vary widely in
their
release engineering habits.
So, in my opinion the decision to use a git snapshot as the basis
for a
package - and how to name that package - should come down to team
judgement about what the distro needs in that specific
case. However, I
do think it's reasonable to expect that unusual choices will be
documented with comments in the package definition.
Cheers,
Jason
