Hi, I have couple of additional questions:

1. How is S-RAMP going to handle maven uploads of artifacts with the same GAV ? It will fail? I would assume that they should be overridden.

2. Is there going to be some versioning support, once the artifact content update is removed?

3. Since this is a minor release, wouldn't this break backwards compatibility (in FSW)?

Hi,

I agree with Stefan. Are all the artifacts that are meant to be uploaded to DTGov already Final. If there is a bug in an artifact, is there a need to deploy a new version, so in that case:

• S-Ramp should avoid or have different way of managing Final releases versus Snapshots. Policies can be enforced on type of artifacts (like nexus does) so a final artifact can never be redeployed and a snapshot version can be.
• DTGov should have the ability to manage this (with different workflows to pre-release (snapshosts) vs released (Final) artifacts)
• If backward compatibility is broken, provide a migration path to upgrade from version to version, but don't stop implementing required features with this argument, as current adoption is low, and the sooner the better.

Cheers,

Hi Brett,

I suppose that we should be flexible to let organizations decide when the artifact is final. Some prefer to go through some development while others prefer to mark them final after all the testing. Of course this is not nexus, but will store artifacts in a similar way, but as nexus, snapshots represent a view of the artifact in a early stage but it is treated as the same artifact.

While if you think the Jenkins way, every build should be trackable for every version of any artifact.

I see dtgov should be a mix of both and allow to define workflows flexible to fit every organization, and not limiting them, otherwise it will be not easily adopted.

My opinion.

In 0.5.0.Final, if SNAPSHOT support is enabled, we are considering the timestamp (included on the jar filename) as a part of the GAV.  So, if, for example, your CI is deploying SNAPSHOTS to S-RAMP, each new version of the artifact technically creates a completely new artifact (the timestamp gives it uniqueness), rather than updating.  However, note that we don't currently automatically create the timestamp if it's not on the jar filename, but we'll add that soon.

I think this is the most important part and should be repeated, which I will do.    When snapshots are enabled in s-ramp, each snapshot is an entirely new artifact.  So the change to no longer allow updating of content doesn't impact this functionality.

I'm perfectly ok with the fact that each snapshot deployment is a new artifact. My point is that users won't be able to update e.g. pure Text Document (*.txt, *.doc). Afaik, S-RAMP is supposed to be a general repository for all enterprise artifacts (not just a maven repo). I suppose this includes storing planning/design documents, as well. So, once a PM/BA deploys a shared document to S-RAMP no one will be able to modify it? Please correct me in my point of view if it is incorrect.