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 -~----------~----~----~----~------~----~------~--~---