New MacPorts release and immediate future plans

[Rainer Müller]

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