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.
Re:next version
Stevan on 2008-01-25T16:00:11
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
autobox
chorny on 2008-01-25T16:54:32
It does require patching in 5.10, but only for Windows. See RT for details.Re:autobox
Alias on 2008-01-25T18:40:26
I don't apply patches to Perl.
So I assume it will appear when 5.10.1 arrives.
I still don't see where the difficulty is. 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%
Re:Installing into other locations
sigzero on 2008-01-25T14:54:05
I second this. Let me decide where I want to put it and what to name the install directory.
vote++Re:Installing into locations other than C:\strawbe
Alias on 2008-01-25T15:43:38
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 DOES Just Work, but your one isn't good enough I'm afraid.
Re:Installing into locations other than C:\strawbe
Corion on 2008-01-25T17:50:54
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 the Strawberry perl.exe and
.pl files correctly upon installation. So the need for manipulation of $ENV{PATH} is lessened. This is of course only a stopgap until you (optionally, but by default) set up $ENV{PATH} correctly for any location and not only for c:\strawberry.
Re:I refuse to limit people...
Alias on 2008-01-31T23:35:04
> Right! Imagine a CGI script opening a console, for Christ sake...... via a Start Menu shortcut :)
