Introducing sfPropelORMPlugin #51

Closed
willdurand opened this Issue Aug 9, 2011 · 16 comments
@willdurand
Propel member

Hi there,

The current sfPropel15Plugin plugin is available at http://www.symfony-project.org/plugins/sfPropel15Plugin but it is not synchronized with this repository. We should mark it as "deprecated" or to synchronize it with this Github repository.

Moreover, this plugin works with both Propel 1.5 and 1.6. The name of this plugin is not really consistent. People who wants a symfony plugin for Propel 1.6 often misses this plugin and that's bad.

Today, the SVN repository is no more maintained and SVN users have to use the SVN access feature provided by Github. But, Github is not able to offer a full-featured SVN service and to create an external on a specific directory seems impossible.

That's why we should change the sfPropel15Plugin to a new plugin named sfPropelORMPlugin which will probably breaks BC. Actually, it will be more consistent to have a plugin with that name and we will change the vendor directory structure from:

lib/vendor
 |_ propel
 |_ propel-generator 
 |_ phing

to:

lib/vendor
 |_ propel
 |    |_ runtime/lib
 |    |_ generator
 |
 |_ phing

So, it will solve the problem for both Git and SVN users as we will be able to create submodules or externals from Github repositories. But yes, it will break BC.

It's not really a problem for SVN users that uses the plugin from www.symfony-project.org because they are not up to date and it will give them a chance to be up to date :)
It's not a problem for Git users as they are not able to use submodules for propel and propel-generator directories expect with a non official repository synchronized with SVN. Note that the plugin will contain a submodule for the Propel lib.

For me the problem is about how to maintain both sfPropel15Plugin and sfPropelORMPlugin ? Should we do or should we arbitrary rename this repository and the plugin for sfPropel15Plugin to sfPropelORMPlugin with a README file that explains how to update ?

I'm +1 for the last assertion but it won't be a one man decision.

Regards,
William.

@fzaninotto
Propel member

I think it should be called sfPropelORMPlugin, and we should remove the version from the name. The only reason it wasn't named sfPropelPlugin in the first place was because it conflicted with the plugin bundled with the framework.

If we keep a version number in the plugin's name, we will always face the issue of having to rename it for better clarity.

@willdurand
Propel member

Agreed. I edited the issue with the sfPropelORMPlugin name.

What about breaking BC ?

@garak

+1 for Will

@nibsirahsieu

i'm +1 for sfPropelORMPlugin.

@fzaninotto
Propel member

Why do you have to break BC? Even if the vendors lib is reorganized, the plugin code should be arranged to keep the BC.

@adlogix

+1 for sfPropelORMPlugin

@themouette
Propel member

+1 for sfPropelORMPlugin

@fabienpomerol

+1 for sfPropelORMPlugin

@casivaagustin

+1 for sfPropelORMPlugin

@K-Phoen

+1 for sfPropelORMPlugin

@zdanozdan

+1 sfPropelORMPlugin

@havvg
Propel member

+1 sfPropelORMPlugin

@jaugustin
Propel member

+1

@rozwell

+1 for sfPropelORMPlugin
I was about to report that we need new installation instruction, so don't forget to update it!

@vworldat

+1 for sfPropelORMPlugin

@willdurand
Propel member

Thank you everybody :)

@willdurand willdurand closed this Aug 18, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment