sounds like a plan!
> Am 16.10.2020 um 13:49 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 > <mailto: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 > > <mailto: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 > > >
