JunyiYi
commented
6 years ago 🤣🤣🤣 That's funny because a major job just done by @pragnagopa is to separate them into two repositories.
Closed brunoborges closed 5 years ago
JunyiYi
commented
6 years ago 🤣🤣🤣 That's funny because a major job just done by @pragnagopa is to separate them into two repositories.
brunoborges
commented
6 years ago Yes, I saw that. But I believe considering how these two projects are tightly coupled as they evolve together, it would be easier to maintain them as in one repository as a multi-modules, yet released independently as Maven artifacts.
Maybe something to consider again, but I understand much work has been done already so definitely not a priority for now.
pragnagopa
commented
6 years ago We understand the tight coupling between these two projects. Long term, we would like to remove this dependency between customer facing SDK and functions host to allow customers to bring in their own dependencies. For example, users can add Java Azure Storage SDK version x to their project but Functions Java worker might have a dependency on version y. Packaging library and worker together will not allow users to bring in their own versions.
Splitting repos is the first step towards decoupling.
brunoborges
commented
6 years ago I believe we have an issue here regarding how -library, -worker, maven plugin, and archetype projects evolve together. Because they all reside in different repos, we can't easily validate whether one is implementing the latest published version of other when contributing or even building actual functions. And if developers are depending on the latest version of library, their functions might not work during runtime because worker/plugin are not always evolved at the same pace/speed as the library.
We must provide a better versioning scheme for these artifacts that is understandable, backward compatible at the very best, and supports evolution of the libraries while decoupled.
My concern is:
It should be clear to developers that if they depend on java-library version X, then the Azure runtime (worker) will support that version, as well the Maven plugin, but because projects have different release processes and live in different repositories, it will not always be the case.
One way to solve this problem is to use the same
Plus, once a new release is out, the pom.xml should change to a -SNAPSHOT version.
Currently, these are the release versions of all related artifacts:
Because versions are not concise, a developer doesn't know which Library version is set up for the archetype version 1.12. Or what version is used by the plugin.
This also makes the life of contributors super hard to develop and build locally.
-- update July 11th, 2018 -- The Functions extension version also has a complete different version history. It is already at 2.11.x (e.g. 2.0.11857-alpha).
This makes developers job extremely hard to work with the Preview and therefore contribute feedback. Also affects usability of the Preview, likely impacting our ability to go GA.
We need a better way to align the versions of these things so it makes it much easier for users/customers to know what they are running.
pragnagopa
commented
6 years ago Thanks for the input. Let's keep this issue to figure out a smoother versioning story. Will get to this once I am done with other higher priority issues.
brunoborges
commented
6 years ago pragnagopa
commented
6 years ago @asavaritayal - Please follow up on this.
jdneo
commented
6 years ago A question about FUNCTION_EXTENSION_VERSION. Shall we pin the version number to a certain minor version in our Archetype?
brunoborges
commented
6 years ago IMO, we should.
selvasingh
commented
6 years ago When we pin, given multiple dependencies, shouldn't we pin a combination of Maven Archetype, Functions library, Java Worker and Maven Plugin?
pragnagopa
commented
5 years ago cc: @paulbatum
Tracking this for GA. We need to lock down on the versions before GA. I will investigate
brunoborges
commented
5 years ago It is extremely important that the versions of the Maven plugin, the Maven artifact, the Worker, and the library are all the same moving forward after GA.
paulbatum
commented
5 years ago @brunoborges I believe you have been giving us this feedback because of the impact of breaking changes during the preview. Please consider the fact that we won't be making breaking changes to 1.0 post GA. Consider the following sequence:
1.0.1.0.1.1.0 and worker version 1.0.1. They did not have to take any actions (this is the point of PaaS). The versions are not in sync.To take your feedback into account, I need you to provide more explanation and background on why keeping the versions in sync is important once there are no further breaking changes. I also need you to weigh in on how you would handle the scenario I described above. Thanks!
pragnagopa
commented
5 years ago Verified SNAPSHOT version of azure-functions-java-library built from dev branch, works with existing functions. Given that we will not be making any breaking changes post GA, no action needed here. Version will follow semver semantics. No breaking changes when updates are pushed to 1.* versions
The two projects (java-library and java-worker) are directly linked to each other given the dependency that worker has on the library.
With that said, I hereby propose the two projects source code are unified into a single repository, yet released independently.
This will facilitate enhancements that impact both projects at the same time, and the release of major versions altogether while still allowing independent releases of minor versions.
The approach is to use a Maven Multi Module project.