If there are not breaking changes on the angular branch now (and I'm not so sure there aren't), then there definitely will be at some point. Chris mentioned tests, there are data model changes, there are changes in how static content will be delivered, etc. Doing that sort of development while having to worry about breaking the production version seems like setting ourselves up for a bad time.
If we want to make the angular branch the primary or only focus of development going forward, we could potentially make a stable branch off of trunk, for bug fixes / release, and develop angular in trunk. On Thu, Oct 31, 2013 at 5:36 PM, Chris Geer <[email protected]> wrote: > Matt, > > The only two considerations from my point of view are: > > 1) I know there have been several times where tests haven't been > functioning on the Angular branch since it wasn't the highest priority. > We'd have to ensure we were far enough along to make sure tests functions > on trunk. > > 2) If we decided to go down the data overhaul we were discussing we'd have > to make sure the changes were applied to both the Angular and existing UI. > Not a show stopper but might be extra work that isn't worthwhile if the > existing UI is going away. > > Chris > > > On Thu, Oct 31, 2013 at 2:31 PM, Matt Franklin > <[email protected]>wrote: > >> I have been taking a look at the angular branch and think that the >> prototype work is awesome. I think it is a huge step forward in >> implementation flexibility. As I was looking through it, I struggled a bit >> with whether or not it needed to be in its own branch. From what I can see >> in the code, it should be possible to run the old and the new ways in the >> same war with very few changes. >> >> What does everyone think about merging the the branch to trunk? IMO it is >> OK to have an incomplete feature in the main branch so long as it doesn't >> negatively impact the core functionality. >>
