+1 in maintaining a separate project and release cycle for side car. We have been running side car in production for 6+ years and the rate of changes to the side car is much higher than to the actual data store. This will enable faster iteration needed for the side car and help folks roll out maintenance fixes easily.
Thanks Roopa > On Aug 17, 2018, at 8:52 AM, Blake Eggleston <beggles...@apple.com> wrote: > > I'd be more in favor of making it a separate project, basically for all the > reasons listed below. I'm assuming we'd want a management process to work > across different versions, which will be more awkward if it's in tree. Even > if that's not the case, keeping it in a different repo at this point will > make iteration easier than if it were in tree. I'd imagine (or at least hope) > that validating the management process for release would be less difficult > than the main project, so tying them to the Cassandra release cycle seems > unnecessarily restrictive. > > >> On August 17, 2018 at 12:07:18 AM, Dinesh Joshi >> (dinesh.jo...@yahoo.com.invalid) wrote: >> >> On Aug 16, 2018, at 9:27 PM, Sankalp Kohli <kohlisank...@gmail.com> wrote: >> >> I am bumping this thread because patch has landed for this with repair >> functionality. >> >> I have a following proposal for this which I can put in the JIRA or doc >> >> 1. We should see if we can keep this in a separate repo like Dtest. > > This would imply a looser coupling between the two. Keeping things in-tree is > my preferred approach. It makes testing, dependency management and code > sharing easier. > >> 2. It should have its own release process. > > This means now there would be two releases that need to be managed and > coordinated. > >> 3. It should have integration tests for different versions of Cassandra it >> will support. > > Given the lack of test infrastructure - this will be hard especially if you > have to qualify a matrix of builds. > > Dinesh > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
