I was referring to peoples ability to contribute overall, not specifically to the Lucee Language feature.
You could of course submit pull requests to assist in the overall Lucee Language feature once the way forward is clear. I don’t think its realistic to assume that every member of the community can be involved in every part of the decision making process.
We are trying to be as inclusive as we can be, and to make sure the best people are involved at the right time. Clearly we won’t get this right all the time. Neither of us were involved in the initial formation of the Lucee Language concept. I certainly wish both of us had been.
Nevertheless, I am certainly a big supporter of the feature and i think it holds great promise. I’m working hard to make sure we get it mostly right
Here is an interesting read on the Apache Way http://theapacheway.com/
Not suggesting that Lucee needs to follow their led but some of these processes are well defined and functioning in other organizations.
The goal is to have a language that can evolve independently from the glacial pace of Adobe’s CFML implementation. If we don’t create a separate dialect on the server, we have the nightmare of trying to support two different implementations in the one language.
The Lucee Language has to start somewhere; the best CFML implementation that the existing server can offer today without a massive engineering effort.
Completely agree that it has to start somewhere. If it is in beta and you can safely remove functionality unitl stable v1, then it’s fine. But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.
But if it is released as v1 now, with all the UI tags for example, then it’s going to be hard to remove them later.
Agreed. I’m personally all for slowing the release of Lucee Lang v1. Concentrate on getting Lucee 5 out of the door without the language extension while we can take the time to specify what’s there now and properly organise a structured consultation period, mission statement, etc.
Follow the node’s example: Have the Lucee lang in beta for as long as you feel comfortable that no more major changes must be applied. This way you can deprecate and remove stuff every once in a while with each new version(of course warnings must be in place long time before such things happen), but you don’t have the commitment to not break backwards compatibility.
Many will say: and which major company will adopt a lang that is in beta? Well, why did they do it with node?