Hi Mark, We put the project in the version, works not back and enables filtering as well as we would have subprojects. It also avoids to have to request new component each time we add a project so think it is a good compromise for us.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 16 oct. 2020 à 13:39, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > Hi, > > What about generalizing use of fix version containing the "target" project > (and we do for openapi or metrics) ? > > I think both component + fix version would be enough to clearly identify > release content/release notes. > > Regards > JB > > > > Le 16 oct. 2020 à 13:34, Mark Struberg <strub...@yahoo.de> a écrit : > > > > hi folks! > > > > Geronimo is an umbrella project. We have tons of tickets, but we > actually cannot make much sense of it tracking wise as the versions in JIRA > is per project and not per module. > > > > That means if we do a release, we do not really have a clean track about > what actually got fixed, right? > > > > Otoh if we would do a distinct JIRA project per actual release artifact, > then we would have 100++ different jira projecs? Just think about all the > many dozen geronimo-spec jars. > > > > How do we want to cope with this in the future? Does anyone have an idea > how this can be improved? > > > > txs and LieGrue, > > strub > > > >
