Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Thursday January 24, 2008
10:14 PM

Request for Features: Strawberry Perl April 2008 Release

[ #35477 ]

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 .msi installer (requires a major rewrite to convert to WiX)

If you want any additions considered beyond this set, speak now.

Discussion welcome in irc.perl.org #win32.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'd like to see DBD::mysql inside Strawberry Perl. And working autobox (requires patching Perl).
    • I don't think autobox still requires a perl patch actually, here is an excerpt from the changelog

      1.00 Tue Apr 12 01:16:52 2005 - rewrite: no longer requires a patch

      - Stevan

  • 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}:

    @echo off
    SET BASE=%~dp0
    path %BASE%\perl\bin;%BASE%\mingw\bin;%BASE%\dmake\bin;%PATH%
    echo "Strawberry Perl Console launched."
    %COMSPEC%

    • I second this. Let me decide where I want to put it and what to name the install directory.

      vote++
    • 1. Win32 Makefile doesn't enable relocation by default, so it hasn't been tested enough for me.

      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
      • 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

  • Right! Imagine a CGI script opening a console, for Christ sake...
    • > Right! Imagine a CGI script opening a console, for Christ sake... ... via a Start Menu shortcut :)