Re: www/firefox-esr instead of www/firefox[0-9]*

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

Martin Husemann <martin%duskware.de@localhost> writes:

> I view it as two differnt variants of a browser, both sharing a common base,
> but basically being a different product:
>
>   - firefox (plain, no version) is on a fast moving release track
>     (I guess upstream thinks the fast moving internet and changing
>     attack scenarios require this). There is a single firefox at any
>     given time, and it is always the latest (aka most secure)
>
>   - firefox esr (plain, no version) is on a slightly slower moving
>     release track but also gets the most important security fixes
>     from upstream. There is only a single real ESR version, as that
>     is what upstream supports.

(Great to have discussion at anytime, but obviously no renaming until
the branch is over.)

I agree that the current naming scheme is troubled.  My concern is that
we are trying to solve multiple versions at once with unclear results,
and secondarily I would like us to avoid problems that the naming norms
aim to avoid.

> And worse, now it gets muddy:
>
>   - firefox52 and similar are outdated, insecure and no longer supported
>     by upstream special versions. They exist for special reasons, like
>     missing hardware or platform support, in the case of 52 for being the
>     last release compilable without a rust compiler and also the last
>     fully portable version.

So DESCR should say that it is no longer supported upstream, and ideally
when that ended.  And it should say clearly that it is or not an ESR.

> In theory there could be multiple versions like 52, but right now there is
> only a need for this special one.

But we have firefox60, an ESR.  That DESCR does not speak to it being
maintained or not.

(People should feel free to update DESCR during freeze; that won't break
anything!)

> IIUC Nia's point is that from an upstream, security and
> user confusion point of view the first two (firefox and firefox-ESR)
> are clearly what upstream defines them to be. Having any other "ESR"
> versions (that really are ex-ESRs) buys nothing. If we need to keep
> a special version that drops (in upstream view) out of ESR support, we
> can renname it firefox$N, to make space for the new official ESR.

Separating all-versioned vs mixed-versioned, you are suggesting to
include ESR in the name of the package, sort of treating it as a
different upstream product, which it sort of is.

> So I am all with Nia, let's have "firefox", "firefox-esr" and whatever
> special versions are needed (currently only "firefox52").

I guess it may be reasonable to add a third path to the version naming
scheme, which is

   foo: the latest stable release of upstream (the version that upstream
   would tell you to run)

   fooN: older releases from upstream, which should only be used for
   special reasons, almost entirely because the main foo does not build
   or run.  These are copied from foo just before foo is updated.  We
   try to avoid having any.

   With this scheme, there is no fooM for versions of upstream that are
   newer than the one in plain foo.  (perfectly ok to be in wip)

which would be different from situations where we need N versions of
something for a long time as other than accomodations for build issues.
For example, I would really not want to see postgresql treated this way,
or asterisk.  I see this as a special case of programs that are almost
stable enough to have one version (treating regular/esr as two
upstreams), but not quite.

Another approach is to have all the ESR versions be versioned, so we'd
have

  firefox-ESR60
  firefox-ESR68

and then it would be clear that they are ESR and which they are, and
from the list, which is newer, etc.

A problem though is what to do when a new firefox release comes out
which is labeled ESR.

Assuming

  firefox-ESR as 68
  firefox as 71

and lets assume 72 comes out as ESR.   I don't want to have naming
churn, so I think that means:

  firefox is updated to 72
  time passes to make sure 72 is really ok
  think if 68 needs to be retained
    if so, add firefox-ESR68 as a copy of firefox-ESR
  update firefox-ESR to 72

in this case, there are two copies of 72.   That will persist until 73
happens.

Does that sound sane?