Sorry for the delayed response. See below. On Thu, 2018-08-02 at 09:18 -0400, Jason E Bailey wrote: > Really, there's so much to this response. I'll try to be as short as > possible just to delineate ideas. > > 1. **Start thinking of Sling as Product** > 2. Define what should be in the product > 3. Change how we handle the individual bundles, categorize them > better, make the javadoc available for each bundle directly from the > website. > > Sling Start is effectively the Sling release. > > Scenario for a Sling Start product. > > 1. A major release of Sling Start occurs > 2. Sling Start is branched for that release. > 3. Any minor changes to bundles that are added to master can also be > added to that release branch, after a certain amount of bug fixes a > release of that branch can occur. And we'd have a point release. A > major bundle change would not go into the release branch, only the > master branch for the next major release of Sling Start. > > I wouldn't say that every bundle update needs to have a release of > Sling Start. But if we've done a release and something doesn't work > in that release, then yes that deserves another release to occur. It > should be a given to someone coming to the site that if they download > a release that the functionality that we promise is there and working > correctly. > > It also might make sense to have multiple releases representing > different needs. One that is just core necessities, another that has > example content, another that is tailored for need 'x' > > If we have a product centered release, it would be easier for someone > downstream to build on top of it. Although I appreciate and get that > launchpad directly should be used by some products, there's a lot of > custom knowledge that someone would have to have to do.
All of the above sounds good to me. And _except_ for the maintenance releases this is something that we should do anyway - bundle categorisation, javadocs, testing before merging, etc. The only thing that stops of from doing maintenance releases is the effort of running a release. Perhaps I'm the only one talking about it since I handled the last 3 releases :-) If anyone wants to volunteer for Sling 11 - with a helping hand from me - I'm be more than happy to pass the torch and then we have more eyes on what is a pretty manual and no-so-exciting process. Robert > > - Jason > > On Wed, Aug 1, 2018, at 1:03 PM, Robert Munteanu wrote: > > On Wed, 2018-08-01 at 08:24 -0400, Jason E Bailey wrote: > > > I would love to see someone create a supported Sling release, > > > kinda > > > like CRX back in the day. One that you could go to and download > > > and > > > you know you're getting a stable set of bundles, and that will do > > > point releases if a bug is discovered. That sort of thing. > > > > In Sling all releases are going forward. It's rare that we do > > maintenance branches. Actually, I think we only have it for the > > Sling > > mocks and for the IDE tooling, so no actual bundles. > > > > The fix is always "pick up the most recent version of the bundle". > > In > > terms of that, we could technically release the Sling Starter as > > well, > > but that is a lot of overhead. > > > > How would you see a stable Sling (Starter?) product approached? > > > > Thanks, > > > > Robert > >
