New track creation for gradle

store-requests
1

Hi,

Gradle just released 7.x and I’d like to keep previous release (6.8.x) as a separate track for maintenance purposes.

cc: @Igor

1 Like
2

Hello,

Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have three questions before casting my vote.

  1. What’s Gradle’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. Is there some commitment from upstream on maintenance of old versions? e.g. is 6.8.x still supported with security updates? will it continue to be supported now that 7.x is out, and for how long?
  3. Are new versions backwards-incompatible? meaning, if I was running 6.8 and try to install 7.0, will that just work, or do I need to migrate my data/configuration, or will things break horribly?

Thanks!

  • Daniel
3

What’s Gradle’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?

Please see this document. According to this doc, they release around every 6 weeks. But I couldn’t find any pointers for major releases.

Is there some commitment from upstream on maintenance of old versions? e.g. is 6.8.x still supported with security updates? will it continue to be supported now that 7.x is out, and for how long?

Please see the last paragraph of the document I shared. I interpret it as they may publish fixes to previous releases so yes they may still do that. On the other hand, the doc states that development carries on with the next release. It doesn’t mention anything like an LTS release.

Are new versions backwards-incompatible? meaning, if I was running 6.8 and try to install 7.0, will that just work, or do I need to migrate my data/configuration, or will things break horribly?

This is actually the reason why I wanted to create a track for 6.x line. Since this is a major release, you may need to do more work than usual and it’s always good to have another working package around. Of course one can easily revert to previous snap revision but what if I don’t have the resources to do it for some time?

Please see this document to see changes required to migrate from 6.x to 7.x. One thing you’ll see that it highly depends on your dependencies and plugins etc. Releases are backwards compatible but dependencies, plugins may not.

4

Thanks for the information. I think it fits the use case for tracks, so I’m +1 on granting these.

@reviewers could someone else chime in on this request?

  • Daniel
5

+1 from me as well for the creation of the new track.

6

@tunix so to confirm, is 6.8.x the track name you want?

  • Daniel
7

Yes, 6.8.x is fine. Thank you!

8

Thanks for confirming. Your track is now ready.

  • Daniel
1 Like
9

OK, now we need to do a couple of things:

  • Merge the PR so that the latest 7.x version goes through default track
  • Create another automation from 6.8.x branch that will push 6.8.3 image to 6.8.x track.

:crossed_fingers: