On Thu, May 29, 2008 at 11:42 AM, <[EMAIL PROTECTED]> wrote: > So there seems to be 3 possible conclusions:
At least, yeah. > - There is any easy way to make these kinds of cascading releases, but we > just don't know about it I don't know of one, but if there is, happy to hear it. > - There is a better way to structure our Maven projects so this doesn't > happen in the first place (keeping in mind that we are happy with how the > code itself is architected currently) Probably partially true. Some things I've considered: - When it's entirely internal, possibly living with a snapshot version. I don't like this, because it reduces the reproducibility, but it would simplify. - Try and ensure that most common code is extensible to the point that I don't need to modify the upstream projects frequently. So, for instance, if I had a common web-testing framework for the company that was in 1.1 (web-testing-1.1) used by my enterprise project (enterprise-project-1.0), and I wanted to alter a class in web-testing, I could do so with a subclass that's specific to enterprise-project-1.0. I could release e-p-1.0 without releasing a new version of w-t, and when I feel like the change is stable and ready to migrate upward, I could release a w-t-1.2 release at my leisure, then migrate e-p to take advantage. I'm sure there are other possibilities in this vein. - This is just the way it is, so we should get used to it If you can live with that answer, my first instinct is that it's at least partially true, yeah. Curious to see other responses. - Geoffrey -- Geoffrey Wiseman
