Re: So many icewms

[Greg Troxel <gdt%lexort.com@localhost>]

nia <nia%NetBSD.org@localhost> writes:

> On Sun, May 19, 2024 at 10:21:42AM -0400, Greg Troxel wrote:
>> Not adequately documented, but we have evolved that a package should be
>> in one of two states
>> 
>>   A) single version in pkgsrc, no version tag in package name
>> 
>>   B) multiple versions, every package has a version tag
>> 
>> and that packages should not transition from B to A unless it is
>> believed they will stay in A for 3-5 years.  Basically, being in state B
>> is a clue about the stability of a package's upstream and/or how the
>> community of upstreams that depend on it behave.  Once it's not ok, my
>> view is that it's likely to be not ok in the future.
>> 
>> And, we try to avoid renaming.
>
> There are probably more exceptions than examples of this rule in action.
> See ee sysutils/mc, sysutils/mc46,
> graphics/ImageMagick, graphics/ImageMagick6,
> databases/mongodb, databases/mongodb3
>
> Right now when I need an old version for something, I haven't
> been moving the new version.

True; things are often not entirely aligned.   And agreed we have a bias
against renaming.   So I guess I see it as a plan to be moving towards
while also refraining from renaming.

We could also end up with packages that have one, recent, version that
is regularly updated, and an occasional old one.   But it seems that
once a package crosses into "need more than one", there's basically
something wrong with the upstream or the collection of depending
upstreams, and it usually isn't "keep up to date, except this one old
version, and we won't need other old versions".

So I could see an alternative formulation that the unversioned name must
be the most recent formal release, and versioned ones are created and
gced as needed.  That describes what we do in some cases fairly well.

To me, the biggest things are

  - don't have an unversioned name that's crufty

  - don't be renaming back and forth every quarter as we decide
    something only needs one, and then needs multiple.  basically,
    needing more than one is a long-term slow property about upstream
    behavior, not a judgement about a point in time.

so I think we agree more than not