It strikes me that this would be best handled in the extension
registry so that each author could handle extension releases as he/she
pleases.
So script/extension could grab whatever is marked as the latest by
default or take an argument for a particular release (which would be
set by the
Why not just use tags and branches?
script/extension install foo --tag=0.5
Sean
Jim Gay wrote:
It strikes me that this would be best handled in the extension
registry so that each author could handle extension releases as he/she
pleases.
So script/extension could grab whatever is marked as
Sounds fine to me, but how would that work with extensions that are
downloaded?
On Oct 5, 2008, at 4:23 PM, Sean Cribbs wrote:
Why not just use tags and branches?
script/extension install foo --tag=0.5
Sean
Jim Gay wrote:
It strikes me that this would be best handled in the extension
Right. It hasn't happened yet, but I really feel we should be trying to
release extensions as gems in situations where a checkout is not
feasible. Gems include a lot of the features that we seem to need and
we wouldn't be reinventing the wheel.
Sean
Jim Gay wrote:
Sounds fine to me, but
On Oct 5, 2008, at 3:36 PM, Marty Haught wrote:
I've been wondering how best to maintain stable and unstable branches
of an extension in Git. Traditionally you'd keep the master as
'trunk' which would be considered unstable and you'd tag official
releases. We could use this approach but I'm
