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
