Nikolay, Saikat, Igniters,
I started migrating the OSGi modules to the ignite-extensions repository and I've got some questions regarding the ignite-extensions project: - We agreed that ignite extensions have their own release cycle, so why do we reference a -snapshot version of Ignite in the project? I thought the extensions should be tested against the latest released Ignite version and Ignite should be tested against the latest released extensions version, shouldn't they? Do we currently use ignite nightly builds for extensions testing? - Does each extension being a submodule of a single project cause any trouble? For example, when we release a certain module, we would want to bump the project version, but only for this specific submodule. Nikolay, for spring autoconfigure, did you do this manually or does maven allow to granularly upgrade the modules' version? --AG |
Hello, Alexey.
> Nikolay, for spring autoconfigure, did you do this manually or does maven allow to granularly upgrade the modules' version? Manually. > I thought the extensions should be tested against the latest released Ignite version It seems, we should try to keep extension Ignite version agnostic. If it impossible, then yes, we should use latest Ignite version. > Does each extension being a submodule of a single project cause any trouble? > For example, when we release a certain module, we would want to bump the project version, but only for this specific submodule I think it’s OK to have separate version for each submodule. > Do we currently use ignite nightly builds for extensions testing? Actually, I don’t know such thing as «extensions testing» :) I test it manually on my local laptop during release. > 13 окт. 2020 г., в 13:24, Alexey Goncharuk <[hidden email]> написал(а): > > Nikolay, Saikat, Igniters, > > I started migrating the OSGi modules to the ignite-extensions repository > and I've got some questions regarding the ignite-extensions project: > > - We agreed that ignite extensions have their own release cycle, so why > do we reference a -snapshot version of Ignite in the project? I thought the > extensions should be tested against the latest released Ignite version and > Ignite should be tested against the latest released extensions version, > shouldn't they? Do we currently use ignite nightly builds for extensions > testing? > - Does each extension being a submodule of a single project cause any > trouble? For example, when we release a certain module, we would want to > bump the project version, but only for this specific submodule. Nikolay, > for spring autoconfigure, did you do this manually or does maven allow to > granularly upgrade the modules' version? > > --AG |
Nikolay,
> > I thought the extensions should be tested against the latest released > Ignite version > > It seems, we should try to keep extension Ignite version agnostic. > If it impossible, then yes, we should use latest Ignite version. > I doubt it's possible at least for OSGi: the published artifacts contain a features definition file that should contain an Ignite library reference. But anyways, a -snapshot dependency implies that an extension developer should build Ignite locally, which may be a tangible barrier for extensions developer. If we try to make extensions version-agnostic, a released version should be fine instead of the -snapshot. > > Do we currently use ignite nightly builds for extensions testing? > > Actually, I don’t know such thing as «extensions testing» :) > I test it manually on my local laptop during release. > I meant the TC test suite which was recently introduced [1]. I assume the suite is run before making a release. [1] https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions |
Hi Alexey,
Thank you for sharing your questions. 1. The extensions modules in master branch are pointing to SNAPSHOT version of ignite-core module so that we can test that master branch of extensions modules are compatible with master branch of SNAPSHOT version of ignite-core module. Our idea was once we cut a release branch then during that time depending on latest Ignite release module we will point release branch dependency to latest ignite-core module version like 2.9.0 and validate the extension release candidate with ignite-core 2.9.0 The teamcity IgniteExtensions project run build using the nightly SNAPSHOT version of ignite-core modules. Here is the discussion thread related to the release process: http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-dependencies-and-release-process-for-Ignite-Extensions-td44478.html 2. I am thinking we can keep the extensions module being a submodule of a single project and when we make a release we make changes in the release branch with a tag name which matches the module we are releasing and update the dependencies and version details in the pom. Please let me know your feedback. Regards, Saikat On Tue, Oct 13, 2020 at 6:24 AM Alexey Goncharuk <[hidden email]> wrote: > Nikolay, > > > > I thought the extensions should be tested against the latest released > > Ignite version > > > > It seems, we should try to keep extension Ignite version agnostic. > > If it impossible, then yes, we should use latest Ignite version. > > > I doubt it's possible at least for OSGi: the published artifacts contain a > features definition file that should contain an Ignite library reference. > But anyways, a -snapshot dependency implies that an extension developer > should build Ignite locally, which may be a tangible barrier for extensions > developer. If we try to make extensions version-agnostic, a released > version should be fine instead of the -snapshot. > > > > > Do we currently use ignite nightly builds for extensions testing? > > > > Actually, I don’t know such thing as «extensions testing» :) > > I test it manually on my local laptop during release. > > > I meant the TC test suite which was recently introduced [1]. I assume the > suite is run before making a release. > > [1] > https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions > |
Free forum by Nabble | Edit this page |