Sorry, I hit sent too soon. My intention is to write up a summary of the changes in two-dot-o so that we all understand where things will be once the merge is done. I will send that shortly.
- Dave > On Nov 21, 2014, at 7:44 AM, Dave Johnson <[email protected]> wrote: > > +1 for merging two-dot-o to master. > > New Core Persistence system added which includes these new modules: > > - Collections > - Graph > - Common > - Queue > > > On Thu, Nov 20, 2014 at 1:23 AM, Todd Nine <[email protected] > <mailto:[email protected]>> wrote: > I also agree that we should move our 2.0 branch into master, since it is > now the primary focus of the project. > > I'm unsure what the official policy surrounding releases and branches are. > IMHO a branch in git is a branch, mater or otherwise, tags to preserve the > commit we release from are what is truly important. > > If we do 1 or 2 more maintenance releases of 1.0 and we're clear with our > tagging of those releases, I feel a "one-dot-o" branch would be sufficient. > > Lewis and Jake, any guidance here? > > Thanks, > Todd > > On Wed Nov 19 2014 at 5:05:48 PM Rod Simpson <[email protected] > <mailto:[email protected]>> wrote: > > > Usergriders, > > > > As most of you know, we have been working on upgrading the entity manager > > and some other core changes. This work has been taking place in the > > two-dot-o branch. The good news is that the 2.0 system is much, much > > faster than 1.0. Additionally, the use of ElasticSearch opens up a lot of > > avenues for us in terms of adding new query grammar. > > > > We are now ready to move this work into master. I am proposing that we > > put the current master into a branch called one-dot-o, then move the > > two-dot-o code into master. Here are the pros and cons as I see them: > > > > Pros: > > This will bring the existing work (and there is a lot of work happening) > > to a more visible platform. All changes will have to be brought in via PR > > and it will allow us to scrutinize the code and work being done more > > carefully. It also validates the 2.0 codebase as the primary focus of the > > project. > > > > > > Cons: > > We don’t currently have an upgrade path from 1.0 to 2.0. This is > > something that we intend to build but it may take some time to accomplish > > (currently we are thinking it is about 2-3 months out, possibly sooner). > > It also could make doing additional releases more difficult (e.g. can we > > release from a branch that isn’t master?) We are ready to release 1.0.1 as > > we have had quite a few contributions, so if we have to release from > > master, then this release needs to happen before putting the 2.0 code in. > > > > > > Thoughts? > > > > Rod > > > > > > > > -- > > Rod Simpson > > @rockerston > > rodsimpson.com <http://rodsimpson.com/> >
