publish master commits with date + commit hash

[dsilva]

Suggested versioning scheme for https://github.com/scala/scala-async/issues/205

[SethTisue]

I think sbt-dynver would be helpful here?

[dsilva]

I'm not too familiar with sbt (we use Gradle for our Scala builds at work) but it looks like grabbing the git commit with sbt-dynver wouldn't be much different from $TRAVIS_COMMIT, right?

[dsilva]

Oh I see what you mean -- are you suggesting that the version should be based on the lastest master version tag? I was thinking of keeping 0.0.$date-$commit as a separate series from tagged releases, but I can see how the versioning scheme from sbt-dynver would work well too.

[SethTisue]

yeah, having the previous tag in the version number helps humans keep track of what they're depending on, and I've found sbt-dynver to be painless to use

[dsilva]

@SethTisue updated to use sbt-dynver

[SethTisue]

the latest sbt-scala-module version brings in sbt-dynver, so it isn't necessary to add it separately anymore

I apologize for neglecting this PR. here of some of the reasons I've had hesitations about it:

• for a while there was a pending upgrade to make all the modules use sbt-ci-release. that is now done, but while it was still in process, it kind of held up thinking about other sorts of changes in this area

• now that we're on sbt-ci-release, perhaps the need for this has lessened. we can publish (except for one manual step, see below) simply by pushing a tag — which is so easy it's not clear that further automation buys much

• we don't usually think about changing the publishing process for a single module, we think about changing it for all the modules at once, via sbt-scala-module. avoiding repetition and maintaining consistency is good, but also increases the amount of work and coordination involved in making a change. just doing scala-async might be a good way to test out the change before making it more broadly, though

• historically we don't do fully automated publishing for any of the modules. most modules are community maintained, but we (the Scala 2 team at Lightbend) retain a final gatekeeping role, in part by dividing the release process as follows: the community maintainer stages the release using sbt-ci-release, then someone from Lightbend has a look and then releases. switching to fully automated publishing is perhaps possible and desirable, but it's another thing to consider. I'm not actually sure if we would need to make some change on the Sonatype end or whether we'd just flip a switch in sbt-ci-release

• I have no idea if our account on Sonatype has any storage limits — we'd want to be sure about that before publishing a large number of ephemeral version-tagged releases

anyway, those are some of the thoughts that swirled around in my mind every time I thought about what to do with this PR

@dsilva not sure if you're still around/interested. but in any case, the status quo remains, if you want to test something, either publishLocal on your own machine, or ask a maintainer to push a tag

[dsilvasc]

@SethTisue Thanks for following up here and for explaining this from Lightbend's perspective. That all sounds reasonable.

The original motivation for this was a situation where there were unreleased changes in master. It sounds like sbt-ci-release addresses that.

At some point, Lightbend might want to try automated/continuous publishing to see if it's a good fit for the open source projects that Lightbend maintains, but maybe for something not as high profile as scala-async.

[dsilvasc]

I don't have a close button here, but feel free to close this :)