A library project to be shared between multiple applications each having its own release-cycle should not be part of a multi-module project used to build such an application and should be an independent project with its own release-cycle.
While this is of course a good idea, especially when starting to create new applications, the library projects will grow with the applications and not independently of them. We cannot start by first investing months to create the perfect will-work-for-ten-years library and only then start coding the application that will, in the first months, only use 10% of all these features. So, realistically, during a development cycle, both the application and the library will grow... (which doesn't mean that we cannot separate them)
Which leads me, for example, to the problem that I still want to automate as much as possible. I would like, for example, to click one button in my build server, perhaps enter some parameters and get a new release candidate of the libraries from the current release branch, update the dependency version of the application to this rc version, make the application an rc (from the application's release branch), install them both into the repository, tag the current status on git and deploy the rc application onto the server.
Especially for bigger projects, I want to keep the amount of manual work needed as small as possible. As much building should be done automatically, if possible. And I would like not having to code a jenkins or maven plugin for that purpose (but of course, I would, if needed, no problem there).
Regards, Flo --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
