I assume that what we are drawing here is slightly influenced by the
ZF's path of big repository with everything - followed by the debate
some of us had on a different thread.
I love the perfectionism (and it will benefit my code depending on the
SF projects). I don't think this change badly affects users much but
developers and forkers.
On 2/18/2011 8:15, Konstantin Kudryashov wrote:
Hi Lukas.
About maintainance of stuff, that Fabien do not lead, we might use
Linus Torvalds convention of responsibility pyramid. Suppose, that
you're leader of TwigBundle development. You fork Symfony and your
fork becomes main development branch for TwigBundle. People send pull
requests TO YOU and you review/merge them. After some time, you make
your own big pull request to Fabien's Symfony repo and Fabien will
merge it almost immediatly, cuz you're the trustee for TwigBundle and
that's your area of responsibility. That's how Linux kernel
development works. So i don't see the problem here.
The real problem is how to solve situation when the new version of
TwigBundle gets released between Symfony releases. New version of
TwigBundle is now stable, but stable branch of Symfony points to
previous version of this bundle. And when we'll have more than 3 such
sub-projects - it will become a hell for users.
I like the idea of separation for every component and bundle. In this
case we need package management tool like Ruby Bundler, that will
solve dependencies and install newest versions of components/bundles
right after they become available. But until we have such tool -
separation of Symfony repository will definetly become a hell for
users, developers & contributors.
--------------------------------------------------
Konstantin Kudryashov (everzet)
http://about.me/everzet/bio
On пятница, 18 февраля 2011 г. at 1:25, Lukas Kahwe Smith wrote:
Hi Fabien,
other approach .. fabien how do you envision that the components be
maintained? especially compared to the current model
do you still think that people should send pulls to fabpot/master,
especially for stuff you do not lead. how do we encourage users to
send them else where in stead?
do we want separate release cycles? for the weak dependencies we
have, how to test out different combinations of versions? or do we
have separate versions but release in sync and since we require full
BC we kind expect things to just continue to work and we do not allow
a component to come out with a BC breaking major version for the
lifetime of Symfony2?
regards,
Lukas Kahwe Smith
[email protected] <mailto:[email protected]>
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com <http://symfony-project.com>
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send it
to security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
Yuen-Chi Lian | www.yclian.com
"I do not seek; I find." - Pablo Picasso
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en