Hi Jordan,
On Apr 14, 2007, at 1:39 AM, Jordan K. Hubbard wrote:
I'm still waiting for a convincing explanation as to why simply
tagging trunk and calling it 1.5 (vs 1.4.1) wouldn't be a perfectly
viable solution and way less pain than merging stuff over. I
haven't heard one yet. :-)
Well, I'm about one svn merge command from where you are.
In creating the 1.4.1 tag last night, all I did was an svn merge of
trunk to release_1_4 branch, and then tagged 1.4.1. So while I had to
type one one more command, we also "buy" the freedom to have the two
diverge more in the future if necessary. Granted, there are other
ways to achieve that, but this seemed a relatively cheap price to pay.
James
- Jordan
On Apr 13, 2007, at 7:25 PM, Paul Guyot wrote:
On Apr 14, 2007, at 11:10 AM, James Berry wrote:
In an effort to expedite small releases of MacPorts, such as
1.4.1, I'd like to suggest that we keep trunk as usable as
possible, whenever we can.
As an example, it's been suggested that the universal variant
support in trunk is relatively immature, while most of the other
changes in trunk would be ready for release. May I suggest that
we put in ./configure --with-universal-variant or a ports.conf
setting to to disable the effect of that variant? This would
achieve two things, I believe:
* Remove the threat of this option from trunk, while still
allowing development and testing of the feature to continue on
trunk.
* Allow easy merging/tagging of 1.4.1 based on a complete merge
from trunk.
James,
Thank you for managing the 1.4.1 release.
I do not understand why the universal variant support in trunk is
immature, and more importantly, what the plan is to make it more
mature. I do not see the advantage of disabling it by default
either. The code was designed to have strictly no incidence or to
induce no behavior change as long as users do not select the
variant +universal to build a port.
As far as the next releases are concerned, I would like to see the
following features (from trunk) becoming public, in order to be
able to benefit from them in portfiles:
- universal variant code
- configure flags (we'll be able to clean *many* ports)
- ignore ssl certificate when fetching (will fix a port that
requires this option)
- new livecheck options
I would like to stress that if the configure flags code isn't
released soon, maintainers who often use trunk might check in code
that will not work for users who often use release, if this hasn't
happened yet. Indeed, the trunk configure flags code provides -I$
{prefix}/include and -L${prefix}/lib in CPPFLAGS by default, and
some software require that.
Paul
_______________________________________________
macports-dev mailing list
[EMAIL PROTECTED]
http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________
macports-dev mailing list
[EMAIL PROTECTED]
http://lists.macosforge.org/mailman/listinfo/macports-dev
