> 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
