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