I see, that actually makes more sense. We can make symfony forge utilize
that information to display the dependencies. I suppose a lot of the
organization problems with the plugins now will be solved by symfony-forge.
I guess we need to get that done :)

- Jon

On 10/23/07, Francois Zaninotto <[EMAIL PROTECTED]>
wrote:
>
> What if I develop a plugin compatible with symfony 1.0, but this plugin
> has its own history of BC breaks for which I want to use my own branche
> numbers?
>
> Imagine that fooBarPlugin 1.0 is compatible with symfony 1.0. I make a
> change in it that makes the new version incompatible with the previous one -
> although still built for symfony 1.0. So I want to create a new branch for
> that new version so that people using the 1.0 branch in svn:externals
> don't break their applications. How should I name the new plugin branch
> then? 1.0.1 ? But doesn't that sound 1.0 compatible? And what if the new
> version is a big jump in features and I think that it deserves more than a
> 0.0.1 difference?
>
> My 2c: dependencies are to be written in the package file and stated
> clearly in the README. Apart from that, authors should be free to name their
> branches.
>
> François
>
> 2007/10/23, Jonathan Wage <[EMAIL PROTECTED]>:
> >
> > Hey all,
> >
> > I know Ian(pookey) had brought up the naming convention we are to use
> > for plugins branches and tags and I think using symfony-x.x.x can be
> > misleading. In another thread Fabien mentioned we should use the exact same
> > naming pattern that symfony uses, and I think we should do that.
> >
> > A plugin branch should almost always relate to the same branch name in
> > the symfony svn. Here are some examples:
> >
> > sfDoctrinePlugin/branches/0.1 - This is a special case. Requires symfony
> > 1.0 branch but is named 0.1 because it was the first version of
> > sfDoctrinePlugin to work on symfony 1.0
> >
> > sfDoctrinePlugin/branches/1.0 - This is the latest symfony 
> > 1.0sfDoctrinePlugin and requires the symfony
> > 1.0 branch
> >
> > sfDoctrinePlugin/trunk(sfDoctrinePlugin/branches/1.1) - This is the
> > latest development of sfDoctrinePlugin and trunk will almost always require
> > the latest development version of symfony. When a plugin becomes stable and
> > launches it should be branched to branches. When symfony 1.2 or symfony
> > 2.0 comes out, the branches/1.1 will be created so that we can continue
> > developing in trunk to make the plugin work with the latest version of
> > symfony
> >
> > sfGuardDoctrinePlugin/branches/0.1 - This is the same special case as
> > above. This version of the plugin requires 1.0 but it was the first beta
> > version and it requires sfDoctrinePlugin/branches/0.1
> >
> > sfGuardDoctrinePlugin/branches/1.0 - Works with symfony 1.0 and requires
> > sfDoctrinePlugin 1.0 branch
> >
> > sfGuardDoctrinePlugin/trunk(sfGuardDoctrinePlugin/branches/1.1) - Works
> > with symfony 1.1 and requires sfDoctrinePlugin 1.1 branch.
> >
> > Now tags should be used for point releases of a branch, but are not
> > totally necessary. The pattern would be as follows.
> >
> > sfDoctrinePlugin/tags/RELEASE_0_1_0, RELEASE_0_1_1, etc.
> > sfDoctrinePlugin/tags/RELEASE_1_0_0, RELEASE_1_0_1, etc.
> > sfDoctrinePlugin/tags/RELEASE_1_1_0, RELEASE_1_1_1, etc.
> >
> > --
> > Jonathan Wage
> > http://www.jwage.com
> > http://www.centresource.com
> >
> >
>
> >
>


-- 
Jonathan Wage
http://www.jwage.com
http://www.centresource.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
-~----------~----~----~----~------~----~------~--~---

Reply via email to