From a customer point of view I would like to see something along the line of the in-place migration of AEM. This is a scenario I can think of:
1. Sling releases a new version 2. Customer shuts down Sling 3. Customer downloads the JAR / WAR file and replaces the old with the new JAR / WAR 4. Customer starts Sling with the new version 5. Sling uses now the OSGi / Felix from the new version and all the new bundles from Sling(start) 6. Customer migrates its bundles / packages to the new Sling version and installs it (if necessary) Another issue I ran into with trying to upgrade to a new Sling version (10) is that I had a hard time to figure out the correct dependencies. It might be great to have a POM of a Slingstart release with all its dependencies or maybe an Uber jar with all code merge into it? Cheers - Andy Schaefer > On Aug 2, 2018, at 6:18 AM, Jason E Bailey <[email protected]> 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. > > - 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 >>
