Juan Manuel Palacios wrote:
If you guys may remember, I suggested a somewhat large rearrangement
of our svn tree a while ago, but all in all I was met with quite a bit
of opposition so I simply dropped it (the initiative at the time, not
the desire to do it ;-).
Wasn't ready for it then, isn't ready for it now. Maybe bring it up
again for MacPorts 2.0... :-)
I also found the post
http://lists.macosforge.org/pipermail/macports-dev/2007-April/
001159.html
I did, however, propose a "test" tree of some sort where we would
instead test MacPorts itself, freely using whatever new
features/constructs that may be in our trunk base code but not in a
MacPorts release at any moment; currently, any new MacPorts feature
has to wait for a new release before being adopted in Portfiles, which
hinders our ability to test. "mysql5" and "mysql5-devel" ports would
both live in the "release" tree if they work with whatever MacPorts
release is current, but (a copy of) any of those would have to move to
the "test" tree if the corresponding Portfile starts using syntax/code
only available in base's trunk. Users would be free to use the "test"
tree against base's trunk or the recommended "release" tree against
the current MacPorts release.
This is somewhat similar, except that "test" and "development" moves in
opposite directions...
i.e. your ports gets pushed from release to "test" when needed for
testing features, whereas the "development" tree gets pushed to
"release" once released (possibly even getting some testing inbetween,
i.e. development -> testing > release)
Normally you'd even have a security branch that leads to backporting
things for old releases.
But that layout is not limited to only those two trees, as any other
purpose-specific tree could be created to fulfill whatever need we may
have should they arise. For instance, platform specific trees could be
created:
/ports
tiger/
aqua/
audio/
(etc)
leopard/
aqua/
audio/
(etc)
Do we really need this....? Certainly not now... but who knows if we
ever do...? ;-) In any case, having the room to grow is a big plus, I
believe, and we don't have it now.
I think that binaries (archives and packages) should be split by
OS/major, but I don't think sources (Portfile and files/) should be
unless it really really has to. That is, I prefer the "platform {}"
variants.
http://lists.macosforge.org/pipermail/macports-dev/2007-July/002033.html
It doesn't really have to split locally (at least not until the
cross-platform development features appear), but it does have to split
on the server side when serving out binary packages or binary archives
(i.e. pre-compiled).
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
