RFC for the Java Buildpack reimplementation in Golang #1392
Conversation
|
LGTM: the only thing we could add is a sort of release plan for expectation management:
Having a 5.0 release (instead of just a branch) may help to get adoption. |
@stephanme thank you for the feedback! It is addressed with f31def3 |
beyhan
changed the title
beyhan
requested review from
a team,
cweibel and
rkoster
and removed request for
a team
|
I think releasing the 5.0.x as an experimentla version is risky, some people might automatically update to this version without knowing this is an experimential version. RC classifiers should probably be used. Just think for example CF-deployment might autobump to version 5 is this really what we want? |
|
I proposed the experimental 5.0 version for transparency. We can name it as we want - the first releases are risky. Of course they will pass cf-deployment validation and CATS - but customers will find gaps and things that don't behave as before. An experimental 5.0 makes clear what to expect and probably there will adjustments to the the list of supported features and deprecations. If it helps, we can also name it beta instead of experimental. |
From the discussion on Slack I now get where this is coming from. Where would that name show up however? |
|
Given that there don't seem to be any open issues with this RFC and work for this is progressing at great speed, the TOC decided to move this to the final comment period. You now have two weeks to leave any comments or forever hold your peace. |
|
Hi, thanks for updating the Java Buildpack. This might also be a good time to review the contents of the build pack as it contains many dependencies... for example the takipi agent where the github does not show activity for the last 12 years: https://github.com/takipi/debugAgent. We also looking forward to include the newest java releases, including Java 25. Is there a way to see what is a good "lean" starting point? |
Hi @stokpop, Thanks so much for bringing this up! We discussed your suggestion during yesterday's TOC meeting, and we really appreciate you highlighting this. The Takipi agent has already been removed from the Go-based Java Buildpack. For a complete overview of what's changed, please check out this comparison document between the Ruby and Go-based implementations. The Go-based version has cleaned up several unmaintained dependencies as part of the modernization effort. Regarding Java 25 support we're definitely looking into including it into the first Go-based release. Since we want the Go-based buildpack to be a drop-in replacement, we'd love to hear your suggestions on any other unmaintained components that should be removed for the Noble version of the Java Buildpack. Your feedback would be valuable you can provide it for example by opening an issue for the buildpack. Also, if you get a chance to test the Go-based version, we'd greatly appreciate any validation feedback you can provide! For this you could use the java buildpack Slack channel. |
Preview