Re: [Hawkular-dev] Release cadence

Hello, There are two issues that get interlaced here and should not be. One is to release individual components on a schedule, and second is making sure that all the components integrate nicely. Your proposal with "at least one release per week" is trying to fix a fix of a fix of previous decision. And in this mix, the two concepts of release and integration get so interlocked that we cannot make heads and tail. Here is the progression of things: Problem 1: monolithic code is bad, we need to componentize everything. Solution: create single purpose repositories, which resulted in about 20 repositories. Problem 2: how do we integrate all those components? Solution: create a Hawkular repository that depends on all the other repositories. Problem 3: integrated project idea works, but how do we really really integrate the code? Solution: publish changes in subcomponents as soon as possible. Problem 4: publishing changes in components takes a long time, can we expedite the process and get changes even faster to integrated project? Solution: automate SNAPSHOT publication so you have freshly build binaries on almost every change. Problem 5: We need consistent builds for the integrated project. Solution: master branch in the integrated project only depends on released version of components, feature branches are short lived. Problem 6: It is almost impossible to align all the release of components and give enough runaway for the integrated project to ingest all the release subcomponets, especially since there inter-dependencies on the sub-projects themselves. Solution: publish sub-components officially at least once per week. Problem 7: There are major changes that are needed right-away in the integrated project. Solution: officially publish components more often than once per week. Publish as soon as the features makes it in. In fact, let's publish Alphas (Alphaxx) with every single change. Problem 8: Too many releases, it takes too much time to administer the process of releasing. Solution: Automate the release dependency management, emulate the SNAPSHOT injection concept but with Alpha "moniker". Problem 9: It is a nightmare to maintain on which version to depend on the integrate project or components that depend on other components. Solution: ?? Problem 10: It is almost impossible to trace back the code that code that goes into the integrated project because there are so many Alphas. Solution: ??? We are at level 5; from 6 forward I see them coming, just as I saw the rest of 5. At what point do we stop and say "wait a second! what we doing here? can we simplify all this??" From my perspective, we are arbitrarily setting requirements just to complicate things. There is always a happy medium and there is always ways to simplify. I would much rather think for 2 months on how to simplify things and do it once, then stack problems that make our lives harder for no reason. That being said, I am not against implementing your proposed solution in Hawkular Metrics. But I see two possible paths. One, escalate and resolve problems 6, and 7 at the same time with automation. That is primarily because we are so thin on resources and so stretched that we do not have time to not automate this. Two, get a release engineer (or another engineer) allocated to the team that will take care of these releases. If we are to proceed with your current proposal please let us know which one of these paths do you want Hawkular Metrics to take. At the same time, we can take the reversed path; rather than escalate problems, remove them from that stack. Why not look to simplify everything, revert a few problems and try to improve our productivity. We can revert to the use of SNAPSHOTS. In what capacity? Let's find the path that gives us the most benefits with the least amount of work. Thank you, Stefan ----- Original Message -----