Versioning parent projects in JIRA ?

Cantor, Scott cantor.2 at osu.edu
Tue Sep 17 12:04:38 EDT 2013


On 9/17/13 11:34 AM, "Ian Young" <ian at iay.org.uk> wrote:
>
>A hypothetical IdP V4 might be fine with the V3 parent POM during
>development until, say, we decided to jump to Java 10.  At that point I'd
>expect us to come up with a V4 parent and migrate things across.  But the
>V3 parent should still be there, and potentially maintained, as long as
>any other project depends on it, i.e., until they can also migrate.  Just
>because the IdP migrates to Java 10, doesn't mean that every other
>project dependent on the V3 parent must do so at the same time.

That actually changes my conclusion that we could ever get away from
maintaining more than one anyway, since we have different products relying
on different foundational POMs.

So I would return to my earlier suggestion:

>> Could we create JPAR2 to isolate the 2.x version and then alter the V3
>> parent versioning going forward to include the major and minor?
>
>If we stick with the integral versions, I think we definitely want to
>split the JIRA structure to avoid cranial implosion.  I care less about
>the naming, but JPAR2 and JPAR3 fit better with the description I gave
>above.  I could live with JPAR for the "current" JPAR and JPAR2 for the
>V2 parent, but I don't think it is optimal: as above, I think we *would*
>want to create a V4 parent POM if and when we want to create a family of
>projects dependent on a new environment, as it's the parent POM that
>encapsulates all of that.  And I definitely don't want to make the
>assumption that we can just decide one day that the V3 parent POM will
>just require Java 10, unless there's only one product underneath.  Which
>there may be, of course, but there may not.

Which is why I think we should create a JPAR2 to handle the older integral
versioning we used already with the v2 parent, and then go forward with
one JPAR for the new stuff and use regular old versioning to track that.

>If on the other hand we move to non-integral versions on the parent
>projects then maybe it can all fit in JPAR without too much trouble.
>Being able to enter just one ticket for a change that needs to be applied
>in all parent projects would be the big upside.

Just to avoid the confusion, I didn't want to go back and start changing
the V2 model we used already, since we have tagged that several times.

-- Scott




More information about the dev mailing list