John Nemeth <jnemeth%cue.bc.ca@localhost> writes: > Some time ago, I solicited opinions about how to handle > comms/asterisk in relation to what version it contains. Currently > it contains 11.x, which goes to security fixes only on Oct. 25th, > 2016, and eol on Oct. 25th, 2017. comms/asterisk18 contains the > Asterisk 1.8 series which went eol last month. The Asterisk 12 > series will go eol next month, so I'm going to skip it. I'm > currently working on creating a package for the Asterisk 13 series, > which has another three years of regular support. > > My current thoughts are to deprecate the use of comms/asterisk, > and go to strictly versioned directories ala Apache, PHP, PostgreSQL, > etc. This means that the Asterisk 13 series will be imported into > comms/asterisk13, and future versions will be imported into > comms/asterisk<version>. Are there any strenuous objections to > this plan? Is so, speak up now, as I could be potentially ready > to do the import any day now (I already have a first cut of the > package with no options and am working making sure all the options > work). I think what you propose is the right approach. My general philosophy is that we should either have only one of a package, with the assumption that everyone should be ok just ugprading when pkgsrc does, or only versioned directories, when upgrading is for some reason harder. This approach runs into problems when packages that used to have stable upstream maintenance decide to break API compat, which is really a 1-version-ok package transitioning into a n-versions package, but asterisk clearly is and has been an n-versions package. I also think, less strongly, that you should probably let comms/asterisk (unversioned) just be until it's time to rm it; the benefits of renaming aren't always worth the trouble with pkgin/pkg_rr/etc. It would be good for each package's DESCR to explain the crufty/stable/new status. > The only glitch that I see with this plan is that Asterisk 18, > which would likely show up in October 2020 would reuse the > comms/asterisk18 directory. Asterisk 18 would be a standard version > with only one year of regular support, so one option would be skip > it. Of course, there are five years to worry about this, assuming > the current release cycle continues. Given that asterisk 1.8 has just passed EOL, it would seem reasonable to remove it significantly before 2020. (I don't know when it's reasonable to tell someone that hasn't updated from 18 to 11 that they are beyond reasonable; my sense is not quite yet based on your earlier comments.) So if asterisk18 is removed by say 2018, then I don't see an issue even if 18.0 is imported. > P.S. See here for Asterisk version timelines: > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions Thanks. Perhaps drop that in DESCR along with "This is old"?
Attachment:
signature.asc
Description: PGP signature