The background is that we could use something like this for Mephisto
to give users a way to avoid version number clashes with their plugin
migrations and future Mephisto migrations. Also I’ve seen situations
where script/generated plugin_migrations causes version number clashes
when two developers worked on different plugins and then tried to
check their generated migrations in to the repository.
The rake tasks above generally avoid these issues. They certainly
aren’t suited for every situation (that’s why the plugin_migration
generator exists), but I believe they work fine for quite some others.
This seems fine - thought it should be clear that for general plugin
usage in “normal” rails development, the plugin_migration generator is
the tool to use.
Directly running migrations from within plugins (via such rake tasks)
should only be required when you need multiple migration streams (i.e.
when building plugins for an externally-maintained application, like
Mephisto).
This seems fine - thought it should be clear that for general plugin
usage in “normal” rails development, the plugin_migration generator is
the tool to use.
Directly running migrations from within plugins (via such rake tasks)
should only be required when you need multiple migration streams (i.e.
when building plugins for an externally-maintained application, like
Mephisto).
Yep, sure.
Go ahead and commit
Just wanted to do so. But I’m confused about the repository layout.
Would that change go to
/plugins/engines only exists for the ‘script/plugin’ script, which was
(until recently, I believe) deeply confused by trunk/branches/tags as
the endpoints of an SVN url
/engines is the part of the repository dedicated to the engines plugin
itself
/engines/trunk is the current development ‘branch’
/engines/tags/rel_1.2.1 is a tag of development that’s stable (and
will never be changed - use this for externals should you wish)
this is basically a special tag for ‘script/plugin’. I’ll update it
when we’re comfortable that we have a version that’s stable and
working for the current release of Rails. Which could be now, given
the lack of noise on the issue tracker
