sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Schaefer <>
Subject Re: Upgrade a site to a new version of Sling
Date Thu, 02 Aug 2018 18:31:37 GMT
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 <> 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

View raw message