As of now the Œsf¹ plugin prefix is reserved for plugins from the core team only. This means in the future as we migrate towards symfony-forge.com, it would be good to get all plugins renamed and split with branches for 1.0 and 1.1. While this is not currently enforced, we can lessen the work load for a faster migration if people can help out sooner rather than later. If you currently maintain a plugin, and plan to make it compatible with 1.1, please help and do your part to make sure there is an easy migration for the community.
Also, we need to figure out how to manage plugins for multiple versions... What do people think is better:
plugins/myPlugin/branches/1.0 -> latest for 1.0 plugins/myPlugin/branches/1.1 -> latest for 1.1 plugins/myPlugin/tags/ -> release tags plugins/myPlugin/runk -> working repo
Or a global version:
plugins/1.0/myPlugin plugins/1.1/myPlugin
What are your thoughts?
I would also like to get a good idea of what plugins are unsupported, of bad quality, or just deprecated. I think it is much more important to only host high quality plugins, rather than just accept all plugins. There should be some mechanisms for quality control and community moderation.
I have gone through plugins I maintain and migrated svn/wiki to use a Œdw¹ prefix for my plugins and Œysf¹ for Y! contributed plugins, as well as deprecated a few old plugins:
Deprecated: * sfSitePlugin for ysfDimensionsPlugin * sfFPDFPlugin for sfTCPDFPlugin
> As of now the ‘sf’ plugin prefix is reserved for plugins from the core > team only. This means in the future as we migrate towards > symfony-forge.com, it would be good to get all plugins renamed and split > with branches for 1.0 and 1.1. While this is not currently enforced, we > can lessen the work load for a faster migration if people can help out > sooner rather than later. If you currently maintain a plugin, and plan > to make it compatible with 1.1, please help and do your part to make > sure there is an easy migration for the community.
> Also, we need to figure out how to manage plugins for multiple > versions... What do people think is better:
> plugins/myPlugin/branches/1.0 -> latest for 1.0 > plugins/myPlugin/branches/1.1 -> latest for 1.1 > plugins/myPlugin/tags/ -> release tags > plugins/myPlugin/runk -> working repo
> I would also like to get a good idea of what plugins are unsupported, of > bad quality, or just deprecated. I think it is much more important to > only host high quality plugins, rather than just accept all plugins. > There should be some mechanisms for quality control and community > moderation.
> I have gone through plugins I maintain and migrated svn/wiki to use a > ‘dw’ prefix for my plugins and ‘ysf’ for Y! contributed plugins, as well > as deprecated a few old plugins:
> Deprecated: > * sfSitePlugin for ysfDimensionsPlugin > * sfFPDFPlugin for sfTCPDFPlugin
I agree on your points and I think it is good that all plugins have a creator-specific prefix. How will you manage the prefixes though? It must somehow be assured that a prefix really belongs to a creator.
One solution would be that each plugin creator "owns" a prefix once he released the first version of a plugin with this prefix and is from then on responsible for namespace conflicts within this prefix. The problem with this approach is that other developers might just be developing plugins with the same prefix.
Especially if we are enforcing high-quality plugins (= longer development time), we have to make sure that development prefixes don't suddenly get "invalid" as someone else released a plugin with the same prefix.
Would a prefix-registration on symfony-forge make sense? Or is this "too much"?
> As of now the 'sf' plugin prefix is reserved for plugins from the core team > only. This means in the future as we migrate towards symfony-forge.com, it > would be good to get all plugins renamed and split with branches for 1.0 and > 1.1. While this is not currently enforced, we can lessen the work load for a > faster migration if people can help out sooner rather than later. If you > currently maintain a plugin, and plan to make it compatible with 1.1, please > help and do your part to make sure there is an easy migration for the > community.
> Also, we need to figure out how to manage plugins for multiple versions... > What do people think is better:
> plugins/myPlugin/branches/1.0 -> latest for 1.0 > plugins/myPlugin/branches/1.1 -> latest for 1.1 > plugins/myPlugin/tags/ -> release tags > plugins/myPlugin/runk -> working repo
> Or a global version:
> plugins/1.0/myPlugin > plugins/1.1/myPlugin
> What are your thoughts?
> I would also like to get a good idea of what plugins are unsupported, of > bad quality, or just deprecated. I think it is much more important to only > host high quality plugins, rather than just accept all plugins. There should > be some mechanisms for quality control and community moderation.
> I have gone through plugins I maintain and migrated svn/wiki to use a 'dw' > prefix for my plugins and 'ysf' for Y! contributed plugins, as well as > deprecated a few old plugins:
> Deprecated: > * sfSitePlugin for ysfDimensionsPlugin > * sfFPDFPlugin for sfTCPDFPlugin
Bernhard Schussek wrote: > Especially if we are enforcing high-quality plugins (= longer > development time), we have to make sure that development prefixes > don't suddenly get "invalid" as someone else released a plugin with > the same prefix.
Also, a prefix which consists of the authors initials seems a bit wrong to me - what happens when that author retires from the project, or the project is developed more by someone else in the future, we shouldn't go going down a path that might lead to people renaming plug ins in the future.
I agree with removing the 'sf' - maybe a standard unofficial prefix is all that's needed... 'usf' perhaps? Or course, this does leave the problem with, for example, having 2 facebook plugins.
> Bernhard Schussek wrote: > > Especially if we are enforcing high-quality plugins (= longer > > development time), we have to make sure that development prefixes > > don't suddenly get "invalid" as someone else released a plugin with > > the same prefix.
> Also, a prefix which consists of the authors initials seems a bit wrong > to me - what happens when that author retires from the project, or the > project is developed more by someone else in the future, we shouldn't go > going down a path that might lead to people renaming plug ins in the > future.
> I agree with removing the 'sf' - maybe a standard unofficial prefix is > all that's needed... 'usf' perhaps? Or course, this does leave the > problem with, for example, having 2 facebook plugins.
I like the idea not having too many different prefixes. If we have two similar plugins, I think they should either merge, add something to their name to make them more descriptive, or change the name.
>Bernhard Schussek wrote: >> Especially if we are enforcing high-quality plugins (= longer >> development time), we have to make sure that development prefixes >> don't suddenly get "invalid" as someone else released a plugin with >> the same prefix.
>Also, a prefix which consists of the authors initials seems a bit wrong >to me - what happens when that author retires from the project, or the >project is developed more by someone else in the future, we shouldn't go >going down a path that might lead to people renaming plug ins in the future.
>I agree with removing the 'sf' - maybe a standard unofficial prefix is >all that's needed... 'usf' perhaps? Or course, this does leave the >problem with, for example, having 2 facebook plugins.
Why do we need prefixes at all? Seems to me, the reason for the sf prefix is to identify those plugins supported by the symfony core team. Once we get away from that, there's no need for prefixes is there?
The elimination of prefixes addresses pookey's concerns and possibly makes it easier for users searching for plugins to more readily identify those created by the symfony core team.
> poo...@pookey.co.uk said on Friday, January 4, 2008:
> >Bernhard Schussek wrote: > >> Especially if we are enforcing high-quality plugins (= longer > >> development time), we have to make sure that development prefixes > >> don't suddenly get "invalid" as someone else released a plugin with > >> the same prefix.
> >Also, a prefix which consists of the authors initials seems a bit wrong > >to me - what happens when that author retires from the project, or the > >project is developed more by someone else in the future, we shouldn't > go > >going down a path that might lead to people renaming plug ins in the > future.
> >I agree with removing the 'sf' - maybe a standard unofficial prefix is > >all that's needed... 'usf' perhaps? Or course, this does leave the > >problem with, for example, having 2 facebook plugins.
> Why do we need prefixes at all? Seems to me, the reason for the sf > prefix is to identify those plugins supported by the symfony core team. > Once we get away from that, there's no need for prefixes is there?
> The elimination of prefixes addresses pookey's concerns and possibly > makes it easier for users searching for plugins to more readily identify > those created by the symfony core team.
On Friday, January 04, 2008, Charley Tiggs wrote: > Why do we need prefixes at all? Seems to me, the reason for the sf > prefix is to identify those plugins supported by the symfony core team. > Once we get away from that, there's no need for prefixes is there?
What about prefixes as dependency indicators?
pBlogPlugin would require Propel while dBlogPlugin would require Doctrine. We can then mix and match: pjBlogPlugin would require Propel and jQuery. Obvious conflicts mean OR: pdBlogPlugin would require Propel or Doctrine.
I think prefixes also make plugin names better keywords. Searching for sfSimpleCMSPlugin is much more likely to return the symfony plugin than just SimpleCMSPlugin.
I don't agree with this solution for the same reason Bernhard pointed
out about prefixes based on creator.
What will happen if the plugin starts with a dependency and will lose
it on the road?
I agree with a single, unique prefix. I saw some suggestions such as
ysf or usf and they both fit the need for me.
Just choose which one we want to use.
-- Simone
On Jan 4, 9:54 pm, Carl Vondrick <c...@carlsoft.net> wrote:
> On Friday, January 04, 2008, Charley Tiggs wrote:
> > Why do we need prefixes at all? Seems to me, the reason for the sf
> > prefix is to identify those plugins supported by the symfony core team.
> > Once we get away from that, there's no need for prefixes is there?
> What about prefixes as dependency indicators?
> pBlogPlugin would require Propel while dBlogPlugin would require Doctrine. We
> can then mix and match: pjBlogPlugin would require Propel and jQuery. Obvious
> conflicts mean OR: pdBlogPlugin would require Propel or Doctrine.
> I think prefixes also make plugin names better keywords. Searching for
> sfSimpleCMSPlugin is much more likely to return the symfony plugin than just
> SimpleCMSPlugin.
project.com> wrote:
> Dustin Whittle wrote:
> > All,
> > As of now the 'sf' plugin prefix is reserved for plugins from the core
> > team only. This means in the future as we migrate towards
> > symfony-forge.com, it would be good to get all plugins renamed and split
> > with branches for 1.0 and 1.1. While this is not currently enforced, we
> > can lessen the work load for a faster migration if people can help out
> > sooner rather than later. If you currently maintain a plugin, and plan
> > to make it compatible with 1.1, please help and do your part to make
> > sure there is an easy migration for the community.
> > Also, we need to figure out how to manage plugins for multiple
> > versions... What do people think is better:
> > plugins/myPlugin/branches/1.0 -> latest for 1.0
> > plugins/myPlugin/branches/1.1 -> latest for 1.1
> > plugins/myPlugin/tags/ -> release tags
> > plugins/myPlugin/runk -> working repo
> yes
> > Or a global version:
> > plugins/1.0/myPlugin
> > plugins/1.1/myPlugin
> no
I sadly miss this discussion (google seems to refuse to send me the
mails from this list, I have to read it manually >> I don't).
As I understand the concern of Sensio and Symfony to preserver his
mark and name (yes, there is ugly things in the plugins). I don't the
current move to {initials}Foo is a good thing. It is a time bomb.
If symonfy-forge needs specific prefix, let create one (sfp for
symfony Plugin for what I care), but reading the current plugin names
I can smell the naming conflicts with external project. Don't forget
that PHP has not yet namespaces and it is not going to be available
widely in a near future.
On Jan 5, 2008 11:41 PM, Pierre Joye <pierre....@gmail.com> wrote:
> As I understand the concern of Sensio and Symfony to preserver his > mark and name (yes, there is ugly things in the plugins). I don't the > current move to {initials}Foo is a good thing. It is a time bomb.
I agree, this makes plugin names looking weirder and more unconsistent, as if they needed such a punishment ;)
So I'm in for two pseudo-namespaces, one for the official plugins and another one for unofficial ones (eg. sf and usf, or whatever.)
But we should act a decision before applying changes to the repos, I guess...
++
-- Nicolas Perriault http://www.clever-age.com Clever Age - conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
