On Tue, Jan 31, 2012 at 08:43:36AM -0700, Tom Christiansen wrote: > > The ticket's more general question remains, about the start of "new". > > I am somewhat leary about calling something "new" (as opposed to "new to > 5.x"), because it's going to be dated soon enough no matter what you do. > Maybe one could use "recent" instead at times, but that still gets stale. > > It doesn't seem to make much sense to call things "new" that appeared in a > release that's no longer supported. Sorry, to be clear, I didn't mean to suggest using an unadorned "new". I still mean "new in v5.8" or "new in v5.12". But I meant that we should pick a release before which we don't feel the need to highlight features added in it at all. And in the future when we move the cutoff forward, trim the parts of the documentation that are no longer accurate in advertising something as new. I don't think that we should be using unadorned "new" at all, even "new in this release", as it will so easily date, and effectively represents a maintenance liability, because they have to be manually corrected in the near future. > I think I myself generally call "recent" the current or previous release, > and stop there. That means 5.12 is recent and 5.10 isn't. But not for long. > Maybe 3 years for recent? Dunno. > > One problem is how vendors take decades to ship recent Perl, so that > changes the recent yardstick to people who just use whatever they > have shoved at them. But that's not our fault, and I don't think > it helps anyone for us to try to cater to it. Agree on ages - 5.8.8 was release 6 years ago today, is still the /usr/bin/perl in at least 2 widely distributed commercially supported Linux distributions. It's subjective, but I disagree on the last part - I think it does help people using or upgrading from these common older versions if we mention in current documentation that features are newer. It acts somewhat as an advertisement in what you could have if you upgraded, and it stops anyone from being confused or frustrated if they are reading newer documentation but working on (or targeting portability back to) an earlier version. (Interestingly, my hunch on what is most common is already wrong - the 2010 Perl Survey showed 5.10.x just ahead of 5.8.x: http://survey.perlfoundation.org/Data-PerlSurvey-2010/R/07_perl_info/index.html However, in 2010, all the firms that I was aware of Perl version were still on 5.8.5 or 5.8.8. Admittedly a small number, but the fact that none had even upgraded to 5.8.9, which should be trivial, suggested that there was uniformity in the lag on organisations whose main application runs on Perl.) Nicholas ClarkThread Previous | Thread Next