MacPorts 1.7.0 without GSoC contributions

[Caspar Florian Ebeling]

In general I think it is not good to hold back features, they should
rather be there and usable once created.

That said, I can understand Ryan's worry very well. There hasn't been
a release in ages, and if the next release cycle is as long as the
current one, the upcoming release better be good, not buggy.

But the real problem is the frequence of releases. Ideally there
would be a release every 4 to 6 weeks, plus bugfix releases, IMHO.
Using such a policy, new features could be integrated immediately
because the cost of a bug would be rather minimal.

If the current release manager does not have the time to do releases,
why can't a new one be appointed, at least for the time being.
It's no shame to be too involved in a day-job or whatever to run an open source
project in the evening, but it's also not helpful not to deal with
consequences. Ryan has hinted several times that he would
not shy away from this job, apparently he has some time at his
hands to work on the project, and he certainly has the necessary
attention to detail. Shouldn't we ask him? And who has to decide this
ultimately?

Florian


On Thu, Aug 14, 2008 at 1:19 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> We have 9 months of development on trunk since 1.6.0. It has several
> new features, not just bugfixes, so it seems big enough and different
> enough to warrant the 1.7.0 version number. Also, we have a bug in
> the 1.6.0 disk image installer whereby the .profile doesn't get
> created. Policy thus far has been to only create disk images for .0
> releases so 1.7.0 would be the first version that could fix that (not
> that I like this policy...).
>
> On Aug 14, 2008, at 05:15, Randall Wood wrote:
>
>> Why not call it 1.6.1 and branch 1.7.0 once the GSoC privileges code
>> is integrated? The Framework is (being) designed to ship as a port.
>>
>> On Wed, Aug 13, 2008 at 5:15 PM, Ryan Schmidt wrote:
>>
>>> I would think we would want to release MacPorts 1.7.0 without the
>>> Google Summer of Code contributions, simply since I expect most users
>>> haven't tested that code yet and we want to release code that's well-
>>> tested. We probably don't need to make a 1.7 branch right now, but I
>>> would keep this in mind so that whenever we do create 1.7.0 we do so
>>> from a point before the GSoC code is merged in (and then merge into
>>> the 1.7 branch changes made on trunk after the GSoC merges if
>>> necessary).
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
Florian Ebeling
florian.ebeling at gmail.com