New MacPorts release and immediate future plans
Anders F Björklund
afb at macports.org
Sun Apr 27 02:21:54 PDT 2008
Juan Manuel Palacios wrote:
> Now, as for the immediate future of MacPorts, I think we all agree
> the time is ripe (or more than) for a new quick release that'll
> incorporate many of the recent enhancements and bug fixes trunk has
> seen recently. I've been collecting ideas and roadmap suggestions
> for what should go into this new issue of MacPorts, but I have been
> away for a while and therefore it's easy for me to miss a thing or
> to. So I'd love to hear what any of you has to say about a still
> theoretical 1.6.5 release (what should go in, what should not, etc).
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...
> We're not making any API incompatible changes at present, so our
> numbers will still be arbitrary to certain degree. But hopefully
> the work that will be put into GSoC and other initiatives too will
> give us enough material to at least conduct a feature-driven
> release cycle.
The only "API" changes is where a new variable is introduced into the
Portfiles, such as the "requires root" setting for running as non-
root, or the "license" or "configfiles" fields for making better
packages. If these are used in ports, then a base needs to be
released to match - at the same time or preferrably earlier. So those
would probably still be reasons for doing a 1.7 or 1.8
> In any case, I propose that from now on we also try to adopt a
> schedule for minor, bug fixing releases, even if a loose one, so
> that after a given number of weeks/months we force ourselves to re-
> evaluate the state of trunk and the current release branch to asses
> what is ready for general consumption and/or in need of a broader
> testing audience. This will also help us fight the perception of a
> stale project.
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 ?
> 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):
> -) my postflight installer bug (already fixed in the release_1_6
> -) what's been done on universal building and choosing of SDK && MDT;
> -) improved fetching code;
> -) improved dependency handling;
> -) improved selfupdate target (my part on this work is done).
The MDT change is a breaking one for Leopard, since it changes if
libraries are built with flat or two-level namespace and such. There
were bugs in older versions of glibtool (i.e. before 1.5.26) that
caused it to pick the wrong settings, if you didn't explicitly say
that you wanted to build for the current native OS version like the
new base does (or were already setting a SDK/MDT such as when
building Universal Binaries with the 10.4u sdk)
So I think the +universal changes should go in 1.7.0 instead,
hopefully after some more feedback and even review. The non-root
changes like applications_dir and frameworks_dir could probably wait
for the new Portfile setting, too.
> I'd love to hear feedback on any and all of the topics touched in
> this mail, but at least on what's relevant for 1.6.5. I'll create
> an appropriate milestone for this new release so that we can start
> classifying tickets accordingly.
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.
But I know that LoggingProposal and MacPorts_Framework are viewed as
prerequisites for those two, so that's probably why they'll have to
wait until after summer. Then those delivered foundations can be used
for the Build Server (PKG) and the Cocoa Application (GUI) "for
More information about the macports-dev