Is the hope for this proposal to avoid having to completely separate the framework from the applications? My first thought reading this was that it would probably be necessary to separate the two so dependencies only go one way (ie applications depend on the framework, framework does not depend on the applications) in order to realistically do this.
Also, if we are considering this sort of approach, why not just go one step further that will make things easier and move the framework to a separate part of SVN with it's own trunk and branches folders, and then only include a binary distribution of that separate framework on the applications side of things? -David On May 4, 2010, at 1:04 AM, Jacopo Cappellato wrote: > What if we start evaluating a different way we organize our svn, daily work > and release strategy? > We may try to move in the direction of having a more stable framework and > more dynamic applications. > > A very simple strategy would be the following one: > > all the changes to the framework (that are not bug fixes) are done in a > separate branch (branches/framework-latest or similar); in this way > trunk/framework will only get bug fixes. > Every 6-12 months (or whenever we want - we can discuss about this) we merge > the branches/framework-latest into trunk/framework and fix the > trunk/applications (of course we could do this in a separate temporary > branch). > > What do you think? > > Jacopo >
