Not that my opinion about Dreamwidth development should hold much sway, but I'll give it anyway.
In all my development work, I usually use the next to last "stable" release of everything unless there is a particular added feature that I really want to use. No matter how long something stays in beta, I tend to find the edge case bug in new versions of languages. I prefer to let other people find it first. :)
Any opinion grounded in experience developing long-lived software (as yours appears to be) is worth considering.
The downside of your specific approach is that (if the Perl PTB stick to their once-a-year release cycle), we need to go through compatibility checks (and fixing) once per year, as opposed to every other year if we jumped to the latest version instead. OTOH, in addition to net getting to get hurt by the latest and greatest bugs that come with the latest and greatest version (as you mentioned), the incompatibilities between 2 successive versions are likely easier to deal with than if jumping 2 versions.
I say we spend some time testing things under 5.14 and see what breaks before we make any decisions. :)
(I believe our general policy should be to stop requiring versions that are no longer supported, but I know that perl upgrades can cause massive problems.)
Ubuntu is currently at 5.10 in 10.04 LTS, and marked as Canonical supported. I doubt that 5.14 will make it into the ubuntu repos untill 11.11 at the earliest.
That being said, find me the .deb and tell me what you want poked, and I'll poke it.
Support by major distribution is one aspect, but not the only one. Others I can list offhand: - Support by perl core developers (fixes for major bugs or security holes) - Support by Perl modules or tools we need to use, or would like to use.
While you are correct that jumping to 5.14 may not be feasible (regardless of the wisdom of trying to), it remains that 5.8 and 5.10 are no longer supported in the ways I listed above, and that preparing to move to a version that is (meaning 5.12 if 5.14 turns out to break too much stuff) is IMO a good idea.
Not arguing that trying to update is a good idea. Kinda all for that, actually.
The consideration in my brain actually is that if we're going to require specific versions that may not be in the standard distro-install channels, we'd prolly wanna provide that version. Prime Example: perlbal.
(I don't know about Dreamwidth development, but I work as a Perl consultant, I give courses in it and I follow the Perl development).
Backwards compatibility is taken very seriously by the Perl developers. There are new features in 5.10, 5.12 and 5.14, but you have to specifically ask to have them activated before you can use them. In general, the most likely reason to get problems when going up to a newer Perl version is that you've accidentally relied on buggy behavior that got fixed, or that you're using a feature that got deprecated (one major version will warn before anything is removed, so only really a surprise if you jump several major versions in one go).
It is much more likely that you'll have problems when upgrading any external modules you rely on, but you'll probably run into that one even if you stay at an old Perl version.
My recommendation: If you just want a newer more-supported Perl version, aim for 5.12.3. I've moved two projects from 5.8.9 to 5.12.3, and it was very smooth both times. If significant work with non-latin alphabets and/or IPv6 is in your future plans, wait a couple of months and try 5.14.1 instead.
The main concern I would have is changes(*) that would cause a string result to have the dreaded "this is... UNICODE!" flag set. For hysterical raisins, Dreamwidth (as LiveJournal) wants all strings to be Unicode (using the UTF8 encoding) but with that flag clear, and clears that flag on all strings returned from code known to set it. When some new code returns a string with that flag set, all strings we combine it with (usually,the rest of the page this string goes into) get turned into gibberish, causing users and developers alike to go "double UTF?".
(*) in the interpreter itself, in core modules, or in any other modules Dreamwidth uses that need to be ungraded to run with the newer perl and core modules)
Oh. In that case I'm sorry to say that there has been extensive work done in that (UTF-8/Unicode) area in every version after 5.8, and that since it sounds like you're using it in a not-really-intended way, you're quite likely to run into problems.
I can definitely see how doing it the way you describe was a good choice a bunch of years ago, but I don't think it is any more. It also sounds like the sort of thing that's a huge amount of dull and fiddly work to change...
Back then (Perl 5.6 or so?), Unicode support in Perl was kinda flaky, if I recall correctly, so it made sense not to rely on it. (Plus LiveJournal originally didn't even support Unicode; that may have influenced the way things were handled. Do you remember the character set conversion widget people had to use to tell the system what charset their previous journal entries were stored in, once Unicode started being used internally?)
Now, doing the Unicode explicitly in Perl would totally be the way to go. But as Calle said, a *huge* amount of dull and fiddly (and error-prone!) work to change.
Once it's done, things will be better (no more opportunities to miss a place where you forgot to tell Perl, "No, I want to do this by myself, the hard way")... but until then... yeah.
Hell, we still have to point some people at the UTF-8 conversion page on LJ, because their old entries were never properly converted and they're trying to import!
But yeah; it's probably the sort of thing we should've done before opening, but it would've delayed us another six months at least, and, meh.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
no subject
In all my development work, I usually use the next to last "stable" release of everything unless there is a particular added feature that I really want to use. No matter how long something stays in beta, I tend to find the edge case bug in new versions of languages. I prefer to let other people find it first. :)
no subject
The downside of your specific approach is that (if the Perl PTB stick to their once-a-year release cycle), we need to go through compatibility checks (and fixing) once per year, as opposed to every other year if we jumped to the latest version instead. OTOH, in addition to net getting to get hurt by the latest and greatest bugs that come with the latest and greatest version (as you mentioned), the incompatibilities between 2 successive versions are likely easier to deal with than if jumping 2 versions.
no subject
(I believe our general policy should be to stop requiring versions that are no longer supported, but I know that perl upgrades can cause massive problems.)
no subject
Ubuntu is currently at 5.10 in 10.04 LTS, and marked as Canonical supported. I doubt that 5.14 will make it into the ubuntu repos untill 11.11 at the earliest.
That being said, find me the .deb and tell me what you want poked, and I'll poke it.
no subject
- Support by perl core developers (fixes for major bugs or security holes)
- Support by Perl modules or tools we need to use, or would like to use.
While you are correct that jumping to 5.14 may not be feasible (regardless of the wisdom of trying to), it remains that 5.8 and 5.10 are no longer supported in the ways I listed above, and that preparing to move to a version that is (meaning 5.12 if 5.14 turns out to break too much stuff) is IMO a good idea.
no subject
The consideration in my brain actually is that if we're going to require specific versions that may not be in the standard distro-install channels, we'd prolly wanna provide that version. Prime Example: perlbal.
no subject
no subject
no subject
no subject
Backwards compatibility is taken very seriously by the Perl developers. There are new features in 5.10, 5.12 and 5.14, but you have to specifically ask to have them activated before you can use them. In general, the most likely reason to get problems when going up to a newer Perl version is that you've accidentally relied on buggy behavior that got fixed, or that you're using a feature that got deprecated (one major version will warn before anything is removed, so only really a surprise if you jump several major versions in one go).
It is much more likely that you'll have problems when upgrading any external modules you rely on, but you'll probably run into that one even if you stay at an old Perl version.
My recommendation: If you just want a newer more-supported Perl version, aim for 5.12.3. I've moved two projects from 5.8.9 to 5.12.3, and it was very smooth both times. If significant work with non-latin alphabets and/or IPv6 is in your future plans, wait a couple of months and try 5.14.1 instead.
no subject
(*) in the interpreter itself, in core modules, or in any other modules Dreamwidth uses that need to be ungraded to run with the newer perl and core modules)
no subject
I can definitely see how doing it the way you describe was a good choice a bunch of years ago, but I don't think it is any more. It also sounds like the sort of thing that's a huge amount of dull and fiddly work to change...
no subject
Siiiiiiiiigh. We needed another one of those like we need a hole in the head...
no subject
Back then (Perl 5.6 or so?), Unicode support in Perl was kinda flaky, if I recall correctly, so it made sense not to rely on it. (Plus LiveJournal originally didn't even support Unicode; that may have influenced the way things were handled. Do you remember the character set conversion widget people had to use to tell the system what charset their previous journal entries were stored in, once Unicode started being used internally?)
Now, doing the Unicode explicitly in Perl would totally be the way to go. But as Calle said, a *huge* amount of dull and fiddly (and error-prone!) work to change.
Once it's done, things will be better (no more opportunities to miss a place where you forgot to tell Perl, "No, I want to do this by myself, the hard way")... but until then... yeah.
no subject
But yeah; it's probably the sort of thing we should've done before opening, but it would've delayed us another six months at least, and, meh.
no subject