All the Perl that's Practical to Extract and Report
use Perl Log In
Alias (5735)
Request for Features: Strawberry Perl April 2008 Release
In line with my attitude that the main Strawberry "product" should be conservative, reliable and predictable (I'm going with a rough analogy to Firefox product-wise) I've been thinking a little about how the release tempo should look.
My current thinking for Strawberry Perl is to do quarterly releases, with a tentative schedule of releases in January/April/July/October and aiming at being available for download before the second Monday of the month.
This will loosely break down to three month-long phases per release.
A month to review the fallout from the previous release, and experiment with new things and decide what should go into the next release.
A month to get the new stuff implemented, ditch the stuff we can't get done, feature freeze and release a beta, and then a month to do the beta-testing, bug fix and give plenty of warning time for anything that needs the stuff in the new release to preview it.
So in line with this schedule, I'd like to hear from people on features that you'd like to see in the April release. The following is my current list.
Features Being Added Already
- A "real" Perl::Dist and Perl::Dist::Strawberry release with proper documentation
- Simultaneous building of multiple versions (Perl 5.8.8 and Perl 5.10.0)
- libwin32 installed by default (based on feedback from cpan.strawberryperl.com download logs)
- Expat and XML::Parser installed by default.
- Auto-upgrading toolchain for CPAN.pm (configure_requires support)
- Standardised build process for C libraries (libgmp accidentally had SSE2 compiled in which broke on some Athlon systems)
- All bundled modules updated to the latest non-broken release.
Features That Won't Be Considered (Probably)
- "Official" Vista Support (upstream C toolchain issues not fully resolved yet)
- Installation to places other than C:\strawberry (non-trivial config and makefile issues stll)
- Availability as an
If you want any additions considered beyond this set, speak now.
Discussion welcome in irc.perl.org #win32.
because that's exactly how much difference there is. :-)
--Larry Wall in <10209@jpl-devvax.JPL.NASA.GOV>
next version (Score:1)
Re: (Score:1)
I don't think autobox still requires a perl patch actually, here is an excerpt from the changelog
- Stevan
autobox (Score:1)
Re: (Score:1)
So I assume it will appear when 5.10.1 arrives.
Installing into locations other than C:\strawberry (Score:1)
I still don't see where the difficulty is [perl.org]. You can skip the "Set up $ENV{PATH}" step in the setup for other locations (like, say, C:\Program Files\Strawberry Perl) and supply a batch file that sets up a "Perl Console" which has the correct $ENV{PATH}:
Re:Installing into other locations (Score:1)
vote++
Re:Installing into locations other than C:\strawbe (Score:1)
2. CPAN.pm and another config file have specific paths (I've made a path-agnostic CPAN.pm for the next release as a first stage).
3. I refuse to limit people to only be able to have working Perl applications if they launch a "Perl Console".
Perl apps should Just Work, regardless of how you run them.
If I do Start... Run... perlapplication, and it fails, it's not good enough.
I'm sure there's a better solution that DOE
Re: (Score:1)
The Win32 Makefile does not enable relocation by default because Perl has always been relocatable on Win32. It's only some modules that aren't without some patching. I've used Perl since 5.6 on Windows in various directories and never encountered any problem that wasn't related to badly written Perl modules that couldn't cope with whitespace in directories.
Double-clicking any Perl program will work even if Perl is not in $ENV{PATH} on Windows, because you (presumably) set up the file association between th
I refuse to limit people... (Score:1)
Re: (Score:1)