Hi Jason, What beyond the ‚engine‘ is actually required? And even the engine is not required to use some sling bundles.
Sling follows a service oriented architecture thst is very loosely coupled and expresses minimal depencies. We shouldn’t try to establish wrong expectations by naming which is why I really don’t like core & controb or extensions. The functional aspect is very personal and Sling starter is just one reasonable combination of modules. The axis of interest are maintenance commitment (indicating commitment of active commiters for module - staring as contribution and ending orphaned) and maturity (experimental, alpha, beta, production ready/ stable , deprecated, maybe discontinued) For maturity: Experimental ( intended for poc - might be quick & dirty) Alpha (active development to cover a full productive scenario) Beta (full coverage for intended use case - feedback cycles might lead to refactorings of smaller parts) Stable (versions > 1.0.0 indicating stable semantic versioning and behavioral stability) Deprecated (better alternatives around or no longer actively updated to work optimally with latest platform) Discontinued (only archival of latest shipped source) For the maintenance commitment I am personally interested how many active willing commiters are around: 0, 1, 2-3, 4+) indicating how likely someone can start to help in case of trouble with module Cheers Dominik Jason E Bailey <j...@apache.org> schrieb am Mo. 24. Sep. 2018 um 15:13: > I still feel like we are missing an axis. One that groups the various > bundles by functionality. > > Maybe: Required, Extension, Optional > > Required are the minimal bundles you need, Extensions are alternatives or > specific implementations of Required, and Optional is just that. > > > - Jason > > On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote: > > On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey <j...@apache.org> wrote: > > > ...I'll throw "community" and/or "community supported" into the ring > for consideration as well. For those bundles that aren't supported... > > > > I like it, as a way to indicate that the PMC expects the community to > > take care of those bundles, on a best effort basis, as opposed to the > > core bundles which the PMC commits to maintaining and keeping in sync > > with the latest evolutions. > > > > That doesn't prevent any community member from working on core bundles > > of course, again it's just an indication of PMC committment. > > > > So we might go for these two axes: > > > > Code maturity axis: experimental, alpha, beta, product-ready. > > > > PMC committment axis: core, community and whiteboard > > > > -Bertrand >
