We must think in users as people doesn't know anythings about us. As well people writing articles about us, will want to check quickly what we do, and we need to be simple and fast. So for me, if I use for example NPM, the last proposal is the correct one:
npm install royale -g If people that land in Royale, see lots of combinations we'll be dead before having the opportunity for that people to reach the great features we can provide So our mantra should be "keep it simple" to be able to make people outside our world have the opportunity to be attracted by our tech. I must to say that we always can change this to something more complex in the future as we get people demanding it, but I'd prefer not to do this at this stage since I'm afraid to lost people due to excessive options, packages and bundles. 2017-10-02 19:25 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > I changed the subject so sorry if this appears like a new thread. > > Let's be a bit more explicit and see if that helps. After getting the > packaging to start to work, I've changed my thoughts a bit. I actually > think I agree with Carlos and Erik. > > I am proposing that we post two different -bin.zip/tar.gz bundles on the > Apache mirrors, which is our main distribution channel. We will only post > one source artifact because the build script can generate both bundles > based on environment variables. We will also post dozens of Jars and SWCs > to Maven Central. And I think we will have an NPM distribution as well. > For the purposes of this discussion, wherever you see .zip, also assume we > are providing a .tar.gz file as well. > > Because we will only have one source artifact, we will call for a vote on > a product named: "Apache Royale x.y.z". The source artifact will be > called: > > apache-royale-x.y.z-src.zip > > We will provide convenience binaries for IDE users. They will be called: > > apache-royale-flexjs-x.y.z-bin.zip (has SWCs for SWF and requires > prerequisites) > > And: > > apache-royale-js-x.y.z-bin.zip (can be unzipped and used as-is) > > If we create other targets in the future, hopefully we will still only > have one source artifact and, for a webasm target the binary artifact > would be called. > > apache-royale-webasm-x.y.z-bin.zip > > I believe this conforms to Apache conventions about artifact names. We > could call the "flexjs" artifact: > > > apache-royale-swf-x.y.z-bin.zip > > But I am mindful of Justin Hill's desire to keep FlexJS in the name > somewhere. > > Meanwhile, everything that goes up on Maven will be under the group id: > > org.apache.royale.compiler (for compiler jars) > org.apache.royale.typedefs (for typedefs SWCs) > org.apache.royale.framework (for framework SWCs) > > Note that in Apache FlexJS 0.8.0, we used the group ids: > > org.apache.flex.flexjs.compiler > org.apache.flex.flexjs.typedefs > org.apache.flex.flexjs.framework > > So there is a project.productname pattern today, but I am proposing that > we don't need a separate product name because the IDE products primarily > differ by which SWCs go in the binary artifacts (there might be a > different default config.xml file too), and Maven users pick their > "product" by choosing which archetype they start with and/or what SWCs > they depend on. > > > Maven artifact names also include a classifier for the target platform. > For example, in the last release, Apache FlexJS posted to Maven Central: > > > > Basic-0.8.0-js.swc > Basic-0.8.0-swf.swc > > I am proposing we keep that classifier pattern as we can probably use a > classifier for WebASM some day as in: > > Basic-0.8.0-webasm.swc > > Last is NPM. I don't know NPM that well, so this could certainly be > wrong. But I think today, you can install Apache FlexJS 0.8.0 by doing: > > > npm install flexjs -g > > > If we are going to use NPM to install the equivalent of the proposed > apache-royale-flexjs-x.y.z-bin.zip then I think that should be called > royale-flexjs in NPM as well so you would type: > > > npm install royale-flexjs -g > > And if you can use NPM to get the equivalent of > apache-royale-js-x.y.z-bin.zip that would be done via: > > > npm install royale-js -g > > But I don't know how many folks will need to do that if you can just unzip > apache-royale-js-x.y.z-bin.zip and use it. Not sure if we need to make > something available just by typing: > > > npm install royale -g > > Thoughts? > > -Alex > > > On 10/2/17, 3:25 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> > wrote: > > >Hi, > > > >my opinion on this regard is that having many sub names (aka product > >names) > >and packages will only confuse people coming to Royale. > >As well, I think we already manage outputs via compiler params to dictate > >if we want to target one or more outputs. > >So I'll be more happy with only one name and only one package that could > >output JS, WASM, SWF, ....) > > > >People coming from Flex will find us and will know we can be their > >solutions > >Meanwhile people that search for a frontend tech, will come to read about > >Angular, React, ...and hope in some time Royale. We don't > >want those people be contaminated for old Flash or Flex that could make > >them not choose us for something is not relevant to us. > > > >So I think we should always look forward and as we decided to remove "JS", > >we should as well not have a "FlexJS" version inside > > > >That's my 2ctn > > > >Thanks > > > >Carlos > > > > > >2017-10-02 11:25 GMT+02:00 Erik de Bruin <e...@ixsoftware.nl>: > > > >> Hi, > >> > >> With the renaming effort planned to start right after the 'packaging' > >> branch lands, I think it makes sense to discuss and vote on the naming > >>of > >> the product(s) of this project. > >> > >> Buried in another thread Alex remarked the following, which I think is > >>an > >> excellent suggestion: > >> > >> "When we were discussing this earlier, we were discussing two > >> IDE-friendly release > >> artifacts, one designed for folks migrating from Apache Flex and another > >> for folks not interested in SWF. In the packaging branch I have most of > >> that working. > >> > >> We were discussing calling the migration package 'FlexJS' and the other > >>one > >> Royale or RoyaleJS. The latter is considered by some folks to mean > >>"Royale > >> for JS". The package names would be apache-royale-flexjs-<version> and > >> maybe apache-royale-royalejs-<version>. The project name would > >>definitely > >> be Royale but I think we want to have artifacts that denote target > >> markets." > >> > >> A strong case has been made to leave off the "JS" off all but the > >> legacy/migration package, which makes sense to me as well. > >> > >> I think there are plans to have this project create multiple product > >>(e.g. > >> one that does AS3->WebAssembly), so I do not think that we should name > >>the > >> current product 'Royale'. It will be increasingly confusing to have a > >> product with the same name as the project and then have other products > >>from > >> the same project with totally different names. I suggest we come up > >>with a > >> naming convention that will reflect the functionality of the various > >> products and their link to the project. E.g. (off the top of my head, > >>just > >> to show what I mean): royale-as-js, royale-as-wasm, etc. > >> > >> What do you think? > >> > >> EdB > >> > >> > >> > >> -- > >> Ix Multimedia Software > >> > >> Jan Luykenstraat 27 > >> 3521 VB Utrecht > >> > >> T. 06-51952295 > >> I. > >>https://na01.safelinks.protection.outlook.com/?url= > www.ixsoftware.nl&data > >>=02%7C01%7C%7Cbff5f7320b37491b462008d5097fed7f% > 7Cfa7b1b5a7b34438794aed2c1 > >>78decee1%7C0%7C0%7C636425367408770456&sdata= > nEfouPWLXrQ1CPihQcCdDFbooP65u > >>S8pKrOUcJvTIp8%3D&reserved=0 > >> > > > > > > > >-- > > > ><https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.codeo > >scopic.com&data=02%7C01%7C%7Cbff5f7320b37491b462008d5097f > ed7f%7Cfa7b1b5a7b > >34438794aed2c178decee1%7C0%7C0%7C636425367408770456& > sdata=%2FF7eVcgTrIhRNo > >yL6GsUiFrhOZt0NT48k7jhbrEqQzk%3D&reserved=0> > > > >Carlos Rovira > > > >Director General > > > >M: +34 607 22 60 05 > > > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.codeos > >copic.com&data=02%7C01%7C%7Cbff5f7320b37491b462008d5097f > ed7f%7Cfa7b1b5a7b3 > >4438794aed2c178decee1%7C0%7C0%7C636425367408770456& > sdata=%2FF7eVcgTrIhRNoy > >L6GsUiFrhOZt0NT48k7jhbrEqQzk%3D&reserved=0 > > > > > >Conocenos Avant2 en 1 minuto! > ><https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Favant2.e > >s%2F%23video&data=02%7C01%7C%7Cbff5f7320b37491b462008d5097f > ed7f%7Cfa7b1b5a > >7b34438794aed2c178decee1%7C0%7C0%7C636425367408770456& > sdata=%2BBVYrV2H3MFg > >4ZkU7VeFER3IkRNmx1D5fKEOnDVGNJA%3D&reserved=0> > > > > > >Este mensaje se dirige exclusivamente a su destinatario y puede contener > >información privilegiada o confidencial. Si ha recibido este mensaje por > >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y > >proceda a su destrucción. > > > >De la vigente Ley Orgánica de Protección de Datos (15/1999), le > >comunicamos > >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC > >S.A. La finalidad de dicho tratamiento es facilitar la prestación del > >servicio o información solicitados, teniendo usted derecho de acceso, > >rectificación, cancelación y oposición de sus datos dirigiéndose a > >nuestras > >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación > >necesaria. > > -- <http://www.codeoscopic.com> Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com Conocenos Avant2 en 1 minuto! <https://avant2.es/#video> Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
