shipkit
shipkit copied to clipboard
To snapshot or not to snapshot
Hey @mockitoguy, great project! This is not the place for it (where is it? Mailinglist somewhere?) but: great project & dedication!!
Now, uhm.. as a previous Maven consultant (converted teams over from Ant back in the days) and newly gradle convert, I am curious about how snapshot versions should or should not be supported by a workflow plugin such as shipkit. I understand that shipkit is all about "every change is a release", so in reality your different versions of..say 0.0.3 built locally are a minor thing. Because on CI, upon commit/push, there will be only one 0.0.3 visible to the world. However, throughout a day (say local commits), i work with many variations of version 0.0.3. So you are the expert on this: is this a problem? I spent weeks explaining teams to stay away from having (even locally) changing values (artifacts) for a non-snapshot version. because every tool consuming things by group/artifact/version coordinates assumes 0.0.3 is a release, and will never change.
Hope you understand this? Would be delighted to hear that this is a non-issue.
Update
Created work ticket: #692 Created PR with design spec: #696
Thank you for kind feedback!
At the moment, shipkit does not prescribe how to develop locally across separate libraries. Snapshots could be used for that purpose. To build and release a snapshot locally, it's the matter of updating the 'version.properties' file. Internally, we don't use snapshots. We would just run 'fastInstall' task to install currently built version to local maven repo.
I spent weeks explaining teams to stay away from having (even locally) changing values (artifacts) for a non-snapshot version
I think I know exactly what you feel :) I agree it's a problem because it may lead to unexpected behavior and extra debugging / troubleshooting. ./gradlew useSnapshot
I am curious about how snapshot versions should or should not be supported by a workflow plugin such as shipkit
At the moment, I would keep things simple and not prescribe the use of snapshots one way or another. Adding explicit support for the local snapshot development should be fairly easy but I'd wait for more feedback / votes on this first.
I brainstormed that idea a little bit, perhaps something like that would be useful:
//in the producer project, installs local snapshot quickly (does not run tests, etc.)
./gradlew snapshot
//in the consumer project, updates the version to use the previously built snapshot
./gradlew useSnapshot
//alternatively, in the consumer project, run any task with snapshot of desired dependency:
./gradlew build -PwithSnapshot=shipkit
Thanks again for feedback!
@mockito/shipkit-developers, any thoughts about the use case?
Thanks for your quick reply, @szczepiq. I agree that as a project promoting fast, very frequent releases (full automation, cool!!!) the time in-between those releases shrinks to a minimum. But maybe i am missing something, but I'd argue running the install task should produce a snapshot because it will only be available on your local machine. I think the Nebula release plugin produces a snapshot version for "snapshot"-task and a dedicated release version (with git commit hash etc) for "devSnapshot"-task. Why would you want to let the install task create a version that will: 1. never be shared beyond your machine (hopefully) 2. frequently overwritten/changed while keeping the version number (which is only save to do using -snapshot versions)?
Good discussion!
Why would you want to let the install task create a version that will: 1. never be shared beyond your machine (hopefully) 2. frequently overwritten/changed while keeping the version number (which is only save to do using -snapshot versions)?
It's a tradeoff. Using snapshots is safer and may prevent some unnecessary debugging. Using the next version and avoiding snapshot distinction is just super simple.
I don't have other arguments :) I would wait and see what other users say and if the current behavior is sufficient. We can add support for building local snapshots a any time if we choose to.
Thank you for feedback!
I'm coming to the conclusion that we need to support snapshots. Otherwise it will be hard to integrate projects that currently use them.