New MacPorts release and immediate future plans

[Anders F Björklund]

  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  
> branch);
> -) 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  
christmas".

--anders