Shibboleth Jenkins now has dependency diagramming; possible parent project anomaly

[Brent Putman]

On 8/15/13 6:37 AM, Ian Young wrote:
> Some of you may already have noticed that our Jenkins instance has acquired the ability to show you the dependencies between jobs.  

Cool!

> One thing I noticed in passing while looking at the above linked charts is that although the V3 dependencies are the way I'd expect to see them (everything is ultimately dependent on the V3 parent project), the V2 dependencies don't all lead back to java-parent-project-v2.  This appears to be because we didn't reset the parent projects of java-xmltooling, java-openws and java-opensaml2 back to TRUNK-SNAPSHOT after the last release, although we did do that for java-shib-common and java-shib-idp2 (these particular dependencies are detected by the Jenkins Maven plugin, so it notices things like this).

I hadn't noticed that before. I think that's just a side affect that I
did the OpenSAML ones and Scott did the IdP ones... So clearly there's
ambiguity about the "right" thing. I consciously left locked to the
parent tag based on what I say below.

I'll also note in passing that the IdP ones are actually in an
inconsistent state wrt parent locking. The POM's point to
TRUNK-SNAPSHOT, but the svn:externals and .checkstyle are locked to a
tag. Should be all one way or the other, I think.



>
> This seems like an anomaly and probably not intended, but reading the product release process page in the wiki...
>
> https://wiki.shibboleth.net/confluence/display/DEV/Java+Product+Release+Process
>
> … I don't actually see a description of when one should unlock a project's parent, so maybe we just need to think about that process and add to the documentation. 

I think you are correct in that it's not made explcitly clear. I think
implicitly the assumption is that you can certainly change the parent
between minor versions (within restrictions based on the versioning
policy), but not necessarily between patch releases within a minor
version, at least ordinarily. Although the latter is unclear, I think.
Based on the versioning policy for patch releases:

- 3rd Party Libraries: identical unless a library upgrade was required
to address a bug corrected by this version

So I guess you could under that condition. But of course there's a lot
more to the parent than just the dependencies, so I think it's unclear.
I'm pretty sure from discussions with Chad that the general intention
was that you don't ordinarily change parent versions across patch
releases. But we're free to change that I suppose.

The problem of when to unlock, though, is the same as we've discussed in
the past re: other areas: What's the "next release" going to be - a
patch release or a minor release (or conceivably even a major)?
Basically it's always just a guess. I think by convention we've
historically assumed that by default the next release is going to be
patch release, unless and until we know otherwise. So that argues for
leaving things in the locked state until it becomes clear that it's
going to be a minor release or some other case for reving the parent, at
which point you unlock from the parent tag (and change the POM and
release notes file, etc).

Also, this reminds me that we don't actually have unlock analogs to the
lock scripts. Probably need those. I'll add a Jira ticket as a reminder.