Anders F Björklund wrote:
There probably needs to be a repackaging of the MacPorts 1.6
installer that includes the correct "postflight" (whether it is
called 1.6.0p1 or 1.6.1 doesn't mattter much). Either that, or the
Guide/instructions should be changed to include how to set up the
PATH variable manually ? But that in itself doesn't need to get any
more features, just help out with the initial MacPorts experience...
The guide already includes how to set up PATH manually.
Wasn't the problem here that PKG installers of MacPorts base are only
made for major releases ? So if there's a bug in say 1.7.0, then it
"needs" a 1.8.0 just to fix it. (using patchlevels like 1.6.0p1 would
also have worked though) Not sure if the new schedule allows for
minor/bugfixes releases too, but otherwise it probably could need
some "beta" or "RC" stage for the next installer package ?
We did have three release candidates for 1.6.0. The problem might be
that nobody really tested it on a clean Mac OS X installation and
therefore we did not catch this bug...
The main thing was that creating PKG installers is a bit more work to
do, especially for all currently supported platforms (Panther, Tiger,
Leopard). Last time it took us about a month to get a PKG installer for
Panther, this time we should create and upload them before we announce
the release.
What should that schedule be? What new features will go into major
releases and which ones into minor releases? Hopefully answering
those questions will encourage us to put our Trac roadmap to better
use, something that has been criticized lately too.
For the moment, I propose we do 1.6.5 with bug fixes against
what's currently shipping in 1.6.0, including (but not limited to):
I see no sense in skipping 4 versions, let's do either 1.6.1 or 1.7.0.
I think it needs a bugfix release (like 1.6.1) from "release_1_6" and
eventually a major release (like 1.7.0) from current trunk -
preferrably with the remaining items for "universal" (merging two
arch builds) and "nonroot" (new setting for ports that *only* work
as root, even if properly relocated) implemented. And then start on a
1.8... I think the biggest missing features in MacPorts are binary
packages (avoid Xcode) and graphical interface (avoid Terminal), at
least when compared to e.g. Fink.
I don't think we can get rid of Xcode fully, variants allow a lot of
combinations and we can't provide binary packages for each and every set
of variants.
Rainer
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
