Rails big pain - uploads and plugin versioning

First of all, congratulations, for rails 2.0 !.
I just want to ask two short questions:

  1. Any plans to improve file uploads ? (now single upload block my
    entire mongrel process) Or any alternatives ?
  2. What about plugin versioning ? Now we have rails 2.0, it would be
    reasonable to do plugin versioning like i.e. does for its extensions
    so every plugin applies only to a specific version(s) of application.

On 9 Dec 2007, at 09:17, Nowy wrote:

First of all, congratulations, for rails 2.0 !.
I just want to ask two short questions:

  1. Any plans to improve file uploads ? (now single upload block my
    entire mongrel process) Or any alternatives ?

not something I’ve ever used

  1. What about plugin versioning ? Now we have rails 2.0, it would be
    reasonable to do plugin versioning like i.e. does for its extensions
    so every plugin applies only to a specific version(s) of application.

I believe the long term future here lies in gems (ie plugins that are
gems). gems already have versions, locking to specific versions/ranges
etc… so it makes sense to leverage this rather than rewrite it.

Fred

  1. What about plugin versioning ? Now we have rails 2.0, it would be
    reasonable to do plugin versioning like i.e. does for its extensions
    so every plugin applies only to a specific version(s) of application.

I believe the long term future here lies in gems (ie plugins that are
gems). gems already have versions, locking to specific versions/ranges
etc… so it makes sense to leverage this rather than rewrite it.

Also note that all plugins coming off SVN repositories implicitly has
version numbers. And if you’re using something like Piston to manage
your SVN externals, it’s really easy to tie yourself to a given SVN
version.

That being said, I’m not necessarily against a more formal scheme. I
just haven’t felt much, if any, pain from the current setup.

DHH wrote:

  1. What about plugin versioning ? Now we have rails 2.0, it would be
    reasonable to do plugin versioning like i.e. does for its extensions
    so every plugin applies only to a specific version(s) of application.

I believe the long term future here lies in gems (ie plugins that are
gems). gems already have versions, locking to specific versions/ranges
etc… so it makes sense to leverage this rather than rewrite it.

Also note that all plugins coming off SVN repositories implicitly has
version numbers. And if you’re using something like Piston to manage
your SVN externals, it’s really easy to tie yourself to a given SVN
version.

That being said, I’m not necessarily against a more formal scheme. I
just haven’t felt much, if any, pain from the current setup.

i never know gems were locked into specific version ranges.
so, with all the depreciated things, you are saying i can’t
get stuck, installing an old gem that has a lot of depreciated things?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs