Re: Upgrade a site to a new version of Sling

[Daniel Klco <da...@gmail.com>]

Theoretically, sling is a sum of the installed bundles so you could create
a Jackrabbit package that updates the bundle versions on an existing
instance.

It would really be up to the end application developer to support such an
upgrade mechanism.

I'm not sure this would work for all version updates (ex: breaking changes
like going from Jackrabbit 2.0 to Oak) but it should work for most.


On Jul 31, 2018 7:10 PM, "Andreas Schaefer" <sc...@me.com.invalid>
wrote:

Hi there

I was just wondering if there is a way to upgrade to a new version of sling
like 9 to 10 without having to export and import my content / configuration.

If I have a blog like Slick or a website using Peregrine and I want to
upgrade to a newer release of Sling exporting all my content might be an
end user nightmare.
For example I can easily upgrade my Wordpress site to a newer version.

Thanks - Andreas Schaefer

Re: Upgrade a site to a new version of Sling

[Jason E Bailey <je...@apache.org>]

I'm good with volunteering with assisting, I'd lead it but I'm pretty sure I don't have the right permissions.

I'll add workflow to my list to look at, when someone commits something to a core bundle, we should be able to automate the integration tests to run automatically. 

Potentially build things such as the docker image automatically as well.


- Jason

On Tue, Aug 21, 2018, at 5:26 AM, Robert Munteanu wrote:
> 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
> > > 
> 
> 

Re: Upgrade a site to a new version of Sling

[Robert Munteanu <ro...@apache.org>]

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
> > 

Re: Upgrade a site to a new version of Sling

[Daniel Klco <da...@gmail.com>]

I've been thinking about this, and really we're already produce all of the
artifacts we'd need via the launchpad / starter builder project, there's
just nothing in place to support the upgrade. I'm not sure we'd even need
to shut down the Sling instance, we could just provide an upgrade mechanism
which extracts the builder JAR, installs the bundles and then parses /
executes the repoinit file.

I would think there'd need to be some concept of a minimum version, e.g.
the oldest version capable of being upgraded to a version, but otherwise we
should be able to support pretty painless upgrades via such a process. The
only other thing I could think that could be a problem is deprecated
bundles as there's not really a good mechanism (at least I can think of) to
differentiate a deprecated bundle and one which is user installed.

WDYT?

On Thu, Aug 2, 2018 at 8:20 PM Jason E Bailey <je...@apache.org> wrote:

> Yeah the dependency thing has always been problematic. I had a contractor
> once did a crazy thing with one of my AEM instances where it became the
> provider of the parent POM through a dynamic generation. Or something like
> that.
>
> Conceivably, The sling starter should be able to generate a file with all
> the bundle dependencies in it.  Or it may even be a value add to have a
> service generate that list.
>
> From an upgrade perspective, you should be able to do exactly what you
> describe. Unless there are additional steps that would need to take place.
> That goes back to thinking of Sling as a product. How would these
> additional steps occur. There should be upgrade documentation etc.
>
> - Jason
>
> On Thu, Aug 2, 2018, at 2:31 PM, Andreas Schaefer wrote:
> > 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
>

Re: Upgrade a site to a new version of Sling

[Jason E Bailey <je...@apache.org>]

Yeah the dependency thing has always been problematic. I had a contractor once did a crazy thing with one of my AEM instances where it became the provider of the parent POM through a dynamic generation. Or something like that.

Conceivably, The sling starter should be able to generate a file with all the bundle dependencies in it.  Or it may even be a value add to have a service generate that list.

From an upgrade perspective, you should be able to do exactly what you describe. Unless there are additional steps that would need to take place. That goes back to thinking of Sling as a product. How would these additional steps occur. There should be upgrade documentation etc.

- Jason

On Thu, Aug 2, 2018, at 2:31 PM, Andreas Schaefer wrote:
> 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

Re: Upgrade a site to a new version of Sling

[Andreas Schaefer <sc...@me.com.INVALID>]

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 <je...@apache.org> 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
>> 

Re: Upgrade a site to a new version of Sling

[Jason E Bailey <je...@apache.org>]

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
> 

Re: Upgrade a site to a new version of Sling

[Robert Munteanu <ro...@apache.org>]

On Thu, 2018-08-02 at 20:22 -0400, Jason E Bailey wrote:
> @Robert What is the "lot of overhead" Is it a lot of work to do a
> release of Sling?

Yes, see 


https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Starter

Robert

Re: Upgrade a site to a new version of Sling

[Jason E Bailey <je...@apache.org>]

@Robert What is the "lot of overhead" Is it a lot of work to do a release of Sling?

- 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
> 

Re: Upgrade a site to a new version of Sling

[Robert Munteanu <ro...@apache.org>]

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

Re: Upgrade a site to a new version of Sling

[Jason E Bailey <je...@apache.org>]

So it's my understanding that the Sling 'releases' are along the lines of a snapshot in time of the core bundles. It provides an opportunity for someone to try out the latest Sling stuff and to publish API's but it's not really a product/project release.

The actual product is the sling starter which defines the bundles that defines the release.

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.


- Jason

On Tue, Jul 31, 2018, at 8:22 PM, Daniel Klco wrote:
> Theoretically, sling is a sum of the installed bundles so you could create
> a Jackrabbit package that updates the bundle versions on an existing
> instance.
> 
> It would really be up to the end application developer to support such an
> upgrade mechanism.
> 
> I'm not sure this would work for all version updates (ex: breaking changes
> like going from Jackrabbit 2.0 to Oak) but it should work for most.
> 
> 
> On Jul 31, 2018 7:10 PM, "Andreas Schaefer" <sc...@me.com.invalid>
> wrote:
> 
> Hi there
> 
> I was just wondering if there is a way to upgrade to a new version of sling
> like 9 to 10 without having to export and import my content / configuration.
> 
> If I have a blog like Slick or a website using Peregrine and I want to
> upgrade to a newer release of Sling exporting all my content might be an
> end user nightmare.
> For example I can easily upgrade my Wordpress site to a newer version.
> 
> Thanks - Andreas Schaefer