Getting a tagged release without subversion, possible?

Rails Engines
1

Hi,

For various reasons, using subversion in our project is not feasible.
It’s important that we maintain stability in our codebase though, so
we only want to include official releases of the Engines plugin. I
was hoping something like this might work: ruby script/plugin install
http://svn.rails-engines.org/plugins/engines/tags/rel_1.0.0, but no
luck, nothing there anyway.

So, I figure either there really is no tagged release there or
subversion is required to get a tagged release. Since I don’t use
subversion, I’m not sure which is true. Can anyone illuminate?
Provide some way to get official releases on into the future? We
could always

For my 2 cents, it’s too bad that plugins are so tied to subversion
in the first place, and I’d really like to see a more flexible and
more gems-like (or any-decent-package-manager-like) method to
distribute them. But I digress …

Thanks for any help,

John

2

Hi John,

Why can’t you use subversion on at least one of your machines to
download a tagged version? Seems like a strange restriction. You could
even do it at home and email it to yourself if you can’t do it at
work.

Peter

3

Hey Peter,

We certainly could do that, and if we decide to use the engines
approach, may have to.

Ok, this is my one-and-only rant here, I swear:

Don’t you think it’s even stranger to install an entire SCM system to
simply use it as a package manager? What could be more restricting
than a technology designed to be used by unknown development groups
(plugins) making such a huge assumption about what kind of SCM system
you’re using or need to use? We don’t use subversion for very good
reasons and I personally consider it a big step backward because it
carries so many of CVS’ problems with it into the future?centralized,
non-atomic, it’s super heavy, and on an on. Darcs, now there’s a
truly modern SCM :wink:

Anyway, just from a practical standpoint, I’d still like to find a
non-subversion way to capture official releases. Might be as simple
as requesting they be posted as tarballs …

Thanks for the suggestion though, seriously.

John

4

On 9/6/06, John C. [email protected] wrote:

we only want to include official releases of the Engines plugin. I
was hoping something like this might work: ruby script/plugin install
http://svn.rails-engines.org/plugins/engines/tags/rel_1.0.0, but no
luck, nothing there anyway.

http://svn.rails-engines.org/engines/tags/ - all the tags you could
ever hope for.

See also the README at the root of the repository.

So, I figure either there really is no tagged release there or
subversion is required to get a tagged release. Since I don’t use
subversion, I’m not sure which is true. Can anyone illuminate?
Provide some way to get official releases on into the future? We
could always

This is actually highlighted in every announcement I make - did you
search?

5

On 9/6/06, John C. [email protected] wrote:

We certainly could do that, and if we decide to use the engines
approach, may have to.

But you won’t be able to stay up-to-date very easily. For example,
when the recent Rails core security issue came up the engines plugin
had to be modified. So you would be driving home to email your self a
copy of the updated version. Seems like a pain.

Anyway, just from a practical standpoint, I’d still like to find a
non-subversion way to capture official releases. Might be as simple
as requesting they be posted as tarballs …

I think it is practical to have SVN installed on your computer if you
are in the Rails world. That way you can do this stuff without
spending any time worrying about it. Just “svn export” and you are
finished. Is there some sort of security problem you are worried about
by having and SVN client on your computer?

Thanks for the suggestion though, seriously.

It’s a way to get started anyway. Engines are very cool.

Peter

6

Hey thanks, that helps.

I guess I missed that somehow while combing the site, sorry.

Any comments on the appropriateness of Engines for hosting multiple
domains on a single app? It’s odd, but in a way we’re trying to
solve the problem solved by Duane with Productize, which is the
inverse problem that engines solve in a way, although they still seem
to make sense, but in a complementary fashion of sorts …

john

7

Hi,

Peter M. wrote:

On 9/6/06, John C. [email protected] wrote:
[…]

Anyway, just from a practical standpoint, I’d still like to find a
non-subversion way to capture official releases. Might be as simple
as requesting they be posted as tarballs …

I think it is practical to have SVN installed on your computer if you
are in the Rails world. That way you can do this stuff without
spending any time worrying about it. Just “svn export” and you are
finished. Is there some sort of security problem you are worried about
by having and SVN client on your computer?

I don’t know of any other language that has a SCM system as a
dependency. For configuration management purposes, you really need a way
of tracking what revision is installed where - pulling untagged releases
from SVN/CVS/whatever is a really bad idea in some environments.

Tarballs have the advantage of being a single, unchanging entity that
can be cryptographically signed, checksummed, etc. to assure the end
user they know what they’re downloading, plus they can easily be stored
on tape, CD, whatever for disaster recovery purposes.

I’m playing devil’s (or John’s) advocate here; while I like the option
of retrieving code via SVN, it still feels risky, like I’m using
bleeding-edge code rather than something tested and approved for release
even if that’s not the case. I’m leery of using SVN as the primary or
sole release mechanism.

YMMV,

– Bob

8

On Sep 6, 2006, at 2:50 PM, Peter M. wrote:

On 9/6/06, John C. [email protected] wrote:

We certainly could do that, and if we decide to use the engines
approach, may have to.

But you won’t be able to stay up-to-date very easily. For example,
when the recent Rails core security issue came up the engines plugin
had to be modified. So you would be driving home to email your self a
copy of the updated version. Seems like a pain.

Very true and a concern.

by having and SVN client on your computer?
I guess we could keep a plugin repository using subversion and keep
that up to date, but we’d then have to suck changes into our working
SCM, darcs. Which might not be too too bad.

Thanks for the suggestion though, seriously.

It’s a way to get started anyway. Engines are very cool.

They are. The only thing that bothers me is that we are looking for a
way to host multiple sites on one physical app, which we are thinking
of deploying as an engine to a bunch of application stubs. I’m not
sure we’re using Engines in the right way here, but it would probably
beat dynamically switching the database connection, etc.

Although, since we’ll probably use mongrel or some other container
mechanism, we’d only have to do that once … so maybe engines are
the wrong choice for us. Still trying to figure that out.

9

On 9/6/06, John C. [email protected] wrote:

I guess we could keep a plugin repository using subversion and keep
that up to date, but we’d then have to suck changes into our working
SCM, darcs. Which might not be too too bad.

No different than if you could get the engines as a tar ball.

They are. The only thing that bothers me is that we are looking for a
way to host multiple sites on one physical app, which we are thinking
of deploying as an engine to a bunch of application stubs. I’m not
sure we’re using Engines in the right way here, but it would probably
beat dynamically switching the database connection, etc.

Do the separate sites have anything shared in the database? If they
are sharing the same database then engines might not be the way to go.

If they really are distinct apps (eg online stores with separate
owners) then engines could be a great way to go.

I think the most important things about engines is choosing the right
time to use them.

Peter

10

On 9/7/06, John C. [email protected] wrote:

Hey thanks, that helps.

I guess I missed that somehow while combing the site, sorry.

Any comments on the appropriateness of Engines for hosting multiple
domains on a single app? It’s odd, but in a way we’re trying to
solve the problem solved by Duane with Productize, which is the
inverse problem that engines solve in a way, although they still seem
to make sense, but in a complementary fashion of sorts …

Engines do indeed solve exactly the inverse of ‘productize’ - that was
exactly their purpose :slight_smile: As such, they’re unlikely to be a good fit
for your particular problem.

  • james
11

On 9/6/06, John C. [email protected] wrote:

Hey thanks, that helps.

I guess I missed that somehow while combing the site, sorry.

Any comments on the appropriateness of Engines for hosting multiple
domains on a single app? It’s odd, but in a way we’re trying to
solve the problem solved by Duane with Productize, which is the
inverse problem that engines solve in a way, although they still seem
to make sense, but in a complementary fashion of sorts …

What will your site do? Details will help people help you.

12

On 9/7/06, James A. [email protected] wrote:

As for releasing tarballs, that puts additional workload on the
developer, and we’re all lazy, aren’t we :slight_smile:

I would much rather see developers develop then spend time releasing
tags in many formats. Deployments, releases, etc are not fun. SVN
works fine and it is better if all plugin developers are using SVN
then some using SVN, some using CVS, some using tar balls, etc.

Peter

13

Hey All,

It wasn’t my intention to start a general plugins deployment
discussion on this specific list, but it might be useful anyway
seeing as how the Engines system is attractive to groups thinking
about ways to do mass deployments and to develop reusable code. We
can keep going offline if you think this is too far OT.

None of the comments so far really change the fact that an SCM system
shouldn’t be in use here at all. SCM systems are not intended and not
suited to be used in this way and, IMO, it is a serious barrier to
adoption of the plugins technology in established development groups
to dictate they have to use a certain SCM system. Wrong, just plain
wrong and just because this is the way things are now doesn’t mean
that’s how they should stay. The fact that installing a plugin is
possible at all without using subversion shows that on some level
someone recognized this as true.

Of course James has made getting a tagged release easy, and that is
good enough for us for now. Thank you, James, we do appreciate that.
This way we can install a particular release of the Engine plugin if
we want and link to it in all our installs.

The “lowest common denominator” rationalization is exactly why we got
stuck with such a crappy tool in CVS for so many years, and
subversion is only a nominal improvement over CVS.

If we would like established groups with a real need for stability in
the environment (e.g. they are rolling out mass deployments) to adopt
plugins like Engines then a better mechanism for releasing,
versioning and controlling plugins as discrete packages is what has
to happen.

We can easily do this for ourselves given what James has graciously
provided, but imagine if you needed subversion installed to get Ruby
installed. How many people do you think would be using Ruby today?
And the fact that RoR uses subversion internally is a total red
herring: subversion is in no way required to get my hands on rails
and use it, nor should it be. The gems system is the real workhorse
in this case, and it’s doing the job it’s designed to do.

Finally, thinking that what I’m saying is that developers should
release tags in a whole slew of different SCM systems and packages in
different file formats misses my point altogether. The plugins
community needs to find a good package management system, not an SCM
system, and use that. Probably be even easier than using any SCM
system out there anyway. What SCM system you use in your projects is
and should be nobody else’s call.

That’s probably all I have to say, for which I bet some are glad :wink:
But it’s a good discussion to have, I think.

Cheers,
John

14

On 9/7/06, Bob A. [email protected] wrote:

I don’t know of any other language that has a SCM system as a
dependency. For configuration management purposes, you really need a way
of tracking what revision is installed where - pulling untagged releases
from SVN/CVS/whatever is a really bad idea in some environments.

… hence why at least the Engines plugin comes with a stable set of
tags, which I heartily recommend that every production site which
uses engines use. Stability is key, people.

I’m playing devil’s (or John’s) advocate here; while I like the option
of retrieving code via SVN, it still feels risky, like I’m using
bleeding-edge code rather than something tested and approved for release
even if that’s not the case. I’m leery of using SVN as the primary or
sole release mechanism.

The reason why SVN is the ‘primary release mechanism’ for plugins is
because it is the only release mechanism. The current script/plugin
tool will ONLY download from SVN repositories. How risky or otherwise
each particular repository’s maintainer, but in general a tagged
release is never modified once created.

Anyway - there is work afoot to retool script/plugin as we speak (see
posts on interblah.net and lukeredpath.co.uk), so in theory there’s no
reason why other SCM systems couldn’t be supported. Even with support
for Darcs (or anything else), you’re just introducing a dependency on
having those tools, plus SVN, for people who would want to download
plugins. SVN is the lowest common denominator, so everyone uses it
because they can be reasonably sure that if they aren’t using it, they
don’t particularly mind installing it. Rails uses SVN, too.

As for releasing tarballs, that puts additional workload on the
developer, and we’re all lazy, aren’t we :slight_smile:

15

On Sep 6, 2006, at 3:38 PM, Peter M. wrote:

of deploying as an engine to a bunch of application stubs. I’m not
sure we’re using Engines in the right way here, but it would probably
beat dynamically switching the database connection, etc.

Do the separate sites have anything shared in the database? If they
are sharing the same database then engines might not be the way to go.

There might be groups of sites sharing a single database, but these
would also be sharing the same stub.

If they really are distinct apps (eg online stores with separate
owners) then engines could be a great way to go.

They may. Doesn’t it feel a bit heave to basically package everything
but the config/cache/etc into an engine though? Maybe not, just
wondering …

I think the most important things about engines is choosing the right
time to use them.

true dat