Stabilize branches

[jmckible]

@techvalidate/engineering lend me your ears:

We must decide how to manage version of Pano. Currently CX is pointed at a feature branch, which may be confusing in the long term. Instead, I propose release branches of either CX or Engage are always targeted to a defined branch convention of pano.

I believe there are two main approaches: app specific or shared version. We're currently modeling the shared version approach: Pano is set to v1.0.0. There is a master branch, which theoretically has all the latest changes, and a 1-0-stable branch which contains all code which is guaranteed compatible (in a SemVer sense). This is how projects like rails operate.

The other approach would be to maintain branches for each major release of CX and Engage. For example, cx-2-2, cx-2-3, etc. This would allow different feature to be applied to different releases of each product.

I'm still thinking through the permutations and I encourage you to do the same. Please leave comments below - I would like to have a consensus by the end of the week.

[mkmiller]

tl;dr shared

I think the current approach is ideal. Yes, we gain a bit of semantic information by doing separate branches for CX vs Engage, and perhaps we would gain some early flexibility. But I believe as time goes on and the product branches become more disparate (and unless we are mindful to keep the branches in sync), we will end up with two distinct versions of Pano. In the long run, we may have more apps incorporating Pano and having product branches sounds like a maintenance challenge to me.

[bullrico]

Agree. Separate branches will be a headache to maintain and keep in sync down the line.

On May 18, 2017, at 8:23 AM, mkmiller notifications@github.com wrote:

tl;dr shared

I think the current approach is ideal. Yes, we gain a bit of semantic information by doing separate branches for CX vs Engage, and perhaps we would gain some early flexibility. But I believe as time goes on and the product branches become more disparate (and unless we are mindful to keep the branches in sync), we will end up with two distinct versions of Pano. In the long run, we may have more apps incorporating Pano and having product branches sounds like a maintenance challenge to me.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/techvalidate/pano/pull/16#issuecomment-302437526, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAa2k92OdSKiJDWgsXwtuDW4UCMSBHIks5r7GJtgaJpZM4Nefxs.

[tjdo]

I think the main consideration is that by using the shared branch convention we are forced to think more about compatibility of Pano, ensuring that the engine is developed with full compatibility and backwards compatibility for all the products we intend to use it for. Branching for product releases could quite possibly get us in a position where we have, at the very least, tech debt which stops us from advancing a branch to the latest code.

My vote is with the shared branch convention.

[jonwolfe]

I agree with the notion that we should strive to not have separate versions of Pano for CX and Engage. Pano releases should move forward and not fork off. However, I think we do need the ability to have CX and Engage running on different releases of Pano, leapfrog-style.

For example, let's say I'm working on a feature for CX that is going to require I change something in Pano. I can make a new release of Pano and set CX to use that new version. Next time Engage is released, we bring its version of Pano up to date and QA the affected parts of Engage.

Does that work?

[jmckible]

The leapfrog should be doable, as long as we set out a clear roadmap. For example, I'm working on Rails 5.1, which will immediately go into Engage, but will need some effort to port to CX. I'll set the pano version to be in the future (say, 1.2), and CX can update to it during v2.4.

How's this for a convention:

master - All of the latest, finished code. Branch off of this to create a new stable release.

Stable release eg 1-0-stable - A long running release branch. To fix a bug, branch off of this, merge it back in, and then merge the stable branch back to master. Releases are tagged off of this branch (eg v1.0.0) and controlled using the Pano version number in Pano::VERSION.

To work on Pano in the context of an app:

Create a new pano branch (off stable for a bug fix, off master for a new release). Set the app to use the local repo. Commit new code to pano, push to github, and create a pull request. Rinse and repeat..

Once the code is ready on the Pano PR, merge it into a stable branch. Put the app through QA.

Once everything is ready for production release, tag a new version of Pano. Update the app Gemfile to use this version - specified by number NOT branch. Then tag the app and release as usual.