2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>: > Definitely a plan. >
Good! :) > > My guess is that if we agree on changing package paths, there will likely > be other classes that should be considered. > For sure I think a 1.0 version should not have "core" packages in "Basic" SWC nor "html" packages in "Core" SWC. I'm pretty sure there's more other cases that we need to structure, reorganize and clean. > 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. > For me we can do that in parallel but if the rest think the same for me is ok. > > 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”… ;-) > > As Piotr, I don't agree with this. I think you missed one important point I posted in other email: All blog post samples posted that are using the actual names, packages and namespaces. If you release 0.9.3 without all that, we can destroy out credibility since in all posts we have: "The example uses the new Jewel UI set that supports themes. Jewel will be available in the forthcoming 0.9.3 release of Royale. In the meanwhile you can find it in the develop branch." and the code is tailored with the actual api. For that reason, I think is important to hold 0.9.3 until it can ship with all that we are promising in website and social networks for the latest 2 months. I think this is crucial. > 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 > > -- Carlos Rovira http://about.me/carlosrovira
