tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: So many icewms



ktnb%netbsd.org@localhost (Kevin Bloom) writes:

> If there is a good reason, could we move the original icewm to
> icewm12 and making icewm3 the default, icewm? My logic for this is
> that most people would want to most up-to-date vesion of a software
> when they go to install it.

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.

So the question is not just if icewm3 is ok as sole now, but if we
expect that as new versions are released by upstream that we can just
update the sole package to that new release, without even having to talk
about it.

Which is a long way of saying, "make the new one icewm3", assuming
consensus is that we should be in state B.

You asked a good and entirely reasonable question, but I'll observe that
there are really separable questions: for each old version, are there
any users and a reason for it to exist?   Often in situations like this,
there are 5, and we decide that we need the current and most recent but
can gc the old ones.

And, if icewm(17) can be gc'd, that takes the "unversioned name exists"
problem off the table.

I have no idea what makes sense for icewm; this is all just meta
commentary about handling multiple versions.



Home | Main Index | Thread Index | Old Index