Definitely a plan. My guess is that if we agree on changing package paths, there will likely be other classes that should be considered.
My preference would be to have this discussion after we finish the project refactor discussion because I think it’s going to be related to the outcome of that. Either way, I don’t think discussion should hold up the 0.9.3 release. We’re already past due for a release. We want to “release early and release often”… ;-) Thanks, Harbs > On May 17, 2018, at 12:07 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Ok, > > what if: > > * I take the time to generate a list of classes with package name changes > * Make a thread with the list to expose it > * Let's see from there if people can live with it (We'll call people to > express about this changes and could see if are or not dramatic to them) > > Sounds this like a plan? > > Thanks > > > > 2018-05-17 10:58 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >> Sure. Same here. >> >> But things are much more stable now. As we move closer to “1.0”, I think >> we should be more careful about breaking changes and documenting them when >> we decide they are necessary. >> >> As far as these specific changes go: We haven’t even come to a conclusion >> on what (if any) package names should change yet, and including those >> changes in a release is premature. If we do change package names, I’m of >> the opinion that they should be decided on and all happen at once to >> minimize impact on end-users. >> >> Does that help clarify things? >> >> Thanks, >> Harbs >> >>> On May 17, 2018, at 11:49 AM, Justin Mclean <jus...@classsoftware.com> >> wrote: >>> >>> Hi, >>> >>>> We are at the point where people are using Royale in production. While >> we can make breaking changes if they are warranted, they should be kept to >> an absolute minimum and be carefully considered and well documented if we >> do. >>> >>> There has been many previous breaking changes that broke the application >> I was working on and some more major than this and cost me a lot of time to >> fix. Until you make it version 1.0 I think people will expect that some >> things may break with a new version. So why should this be an exception to >> what has happened before? Saying that however, what would be good to see is >> to provide guidance to what users need to change so their app works with >> any changes / backward compatibility issues. >>> >>> Thanks, >>> Justin >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
