ok, I can revert this changes in the next few days, so you don't have to deal with this.
2018-07-06 11:39 GMT+02:00 Harbs <[email protected]>: > > but don't you think we can save time and > > resources and left this for 0.9.4 with more refactors we already planned? > > My motivation is to not release undocumented breaking changes — especially > since they might be changed further or reverted in the next release. I’d > like to keep the breaking releases to a minimum. > > I’m willing to make these changes and deal with the extra work. > > Thanks, > Harbs > > > On Jul 6, 2018, at 12:22 PM, Carlos Rovira <[email protected]> > wrote: > > > > Hi Harbs > > > > 2018-07-06 10:27 GMT+02:00 Harbs <[email protected]>: > > > >> Here’s what I’d like to do so we could just get out a release: > >> > >> * Postpone any final decision on package and project refactoring until > >> after the release. > >> > > > > Ok for me, although I think this was one of the things we all agree. But > I > > think you refer that is better to make refactors after 0.9.3 what I think > > is a good idea. > > > > > >> * Make sure (for the current release only) that the package names match > >> the previous release (even if they could use changing). > >> > > > > the list fo changed package names I posted was not final, so this > packages > > can be reverted. The only problem I see is that is a work to give an step > > backwards instead to go forward. That could be done, but just seems to me > > we're giving that part a level of importance that does not match a 0.9.x > > release. If this kind of things was done after 1.x, this would be clear > to > > change it and do it ASAP, but don't you think we can save time and > > resources and left this for 0.9.4 with more refactors we already planned? > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
