dotnet-core-buildpack
dotnet-core-buildpack copied to clipboard
cloudfoundry
Release versioning is not consistent when breaking changes happen
Currently the buildpack semver does not seems to follow industry expectations around when to increment major/minor/patch. This is a problem for customers because buildpacks are typically managed by infrastructure folks who are oblivious to language specific nuances the given buildpack supports. As most often the case they blindly install the latest version. This causes issues when buildpack removes a major version of .NET while there are active apps running on the platform that relied on this version. An example is release 2.3.35 of the buildpack which removed .NET 2.1, but did so as part of a "patch" semver release increment. A patch release should not have major breaking changes like this, so when platform team upgrades none of the deployed apps are able to be restaged.
The proposal is to increment a major version number of the buildpack when any major versions of .NET are removed, and increment a minor version when a major version is added (being that .NET SDKs are backward compatible in most scenarios and should generally not produce breaking changes). This would allow platform team to maintain an older version of the buildpack on the platform under a different name, allowing outdated apps to "peg" against older buildpack.
Should we adopt the same version control as Paketo? Move to triage to investigate.
I am reluctant to change the versioning schema for just one of the buildpacks. I think that this is a much larger conversation that we would need to have for all of the buildpacks and perhaps we should. I don't think that we would want to do something like maintain multiple version lines per buildpack by any means but that is just my opinion.
Why do you need multiple version lines? We're simply talking consistency in incrementing major/minor/patch numbers based on the kind of changes that went into buildpack release
On Tue, Mar 21, 2023, 2:08 p.m. Forest Eckhardt @.***> wrote:
I am reluctant to change the versioning schema for just one of the buildpacks. I think that this is a much larger conversation that we would need to have for all of the buildpacks and perhaps we should. I don't think that we would want to do something like maintain multiple version lines per buildpack by any means but that is just my opinion.
— Reply to this email directly, view it on GitHub https://github.com/cloudfoundry/dotnet-core-buildpack/issues/552#issuecomment-1478367680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAINFWCYIZ6OOJZUFSYTE43W5HVAHANCNFSM5T2DUCJA . You are receiving this because you authored the thread.Message ID: @.***>
Why do you need multiple version lines? We're simply talking consistency in incrementing major/minor/patch numbers based on the kind of changes that went into buildpack release
I see. I apologize I misread your original message.
I still think that this is something that we should talk amongst other buildpacks maintainers so that we can have a significant semver scheme across all of the existing buildpacks. This would be a big shift to apply to just one buildpack and I think that it would just cause more confusion than clarity in some respects.
To do this the right way we need to build the infra to apply the versioning rather than having humans apply it. Will take a bit of work to do it correctly.
Will need to prioritize for later. Moving to icebox for now.