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

Reply via email to