I''m working on a major Rails project who''s code base continues
to grow. The
client wants to have two different versions of the software, with some
features in common between the two, and some features diverging. I''m
trying
to figure out the best strategy for easily maintaining the features the two
have in common, while allowing for differences as well.
Ideas:
- Subversion "branches", doing diffs and merging to maintain
commonality
between both. (Seems like a nightmare.)
- One codebase, w/ configuration settings and if/else statements depending
on which version is running. (Also seems like a nightmare.) For example, the
following type statements littered throughout the code:
if version == "A"
# do version "A" logic
elsif version == "B"
# do version "B" logic
end
- Rails plugins and modules. Seems like the best way, but I''m not sure
the
best way to structure it. Differences will be mostly minor, but at all
levels (views, controllers, models emails)
Any feedback or shared experiences would be great.
Thanks,
--
Scott Becker
Electro Interactive, Inc.
Blog: http://synthesis.sbecker.net
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
SVN branches is one way... another way is to use SVN Externals to manage the common code between many apps. Another option is to move common models, etc into plugins which can be shared. On 6/26/07, Scott Becker <becker.scott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''m working on a major Rails project who''s code base continues to grow. > The client wants to have two different versions of the software, with some > features in common between the two, and some features diverging. I''m trying > to figure out the best strategy for easily maintaining the features the two > have in common, while allowing for differences as well. > > Ideas: > - Subversion "branches", doing diffs and merging to maintain commonality > between both. (Seems like a nightmare.) > > - One codebase, w/ configuration settings and if/else statements > depending on which version is running. (Also seems like a nightmare.) For > example, the following type statements littered throughout the code: > > if version == "A" > # do version "A" logic > elsif version == "B" > # do version "B" logic > end > > - Rails plugins and modules. Seems like the best way, but I''m not sure > the best way to structure it. Differences will be mostly minor, but at all > levels (views, controllers, models emails) > > Any feedback or shared experiences would be great. > > Thanks, > > -- > Scott Becker > Electro Interactive, Inc. > Blog: http://synthesis.sbecker.net > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Another option is Engines: http://rails-engines.org/ On Jun 26, 5:49 pm, "Brian Hogan" <bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> SVN branches is one way... > > another way is to use SVN Externals to manage the common code between many > apps. > > Another option is to move common models, etc into plugins which can be > shared. > > On 6/26/07, Scott Becker <becker.sc...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I''m working on a major Rails project who''s code base continues to grow. > > The client wants to have two different versions of the software, with some > > features in common between the two, and some features diverging. I''m trying > > to figure out the best strategy for easily maintaining the features the two > > have in common, while allowing for differences as well. > > > Ideas: > > - Subversion "branches", doing diffs and merging to maintain commonality > > between both. (Seems like a nightmare.) > > > - One codebase, w/ configuration settings and if/else statements > > depending on which version is running. (Also seems like a nightmare.) For > > example, the following type statements littered throughout the code: > > > if version == "A" > > # do version "A" logic > > elsif version == "B" > > # do version "B" logic > > end > > > - Rails plugins and modules. Seems like the best way, but I''m not sure > > the best way to structure it. Differences will be mostly minor, but at all > > levels (views, controllers, models emails) > > > Any feedback or shared experiences would be great. > > > Thanks, > > > -- > > Scott Becker > > Electro Interactive, Inc. > > Blog:http://synthesis.sbecker.net--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---