Ignite-extensions repository structure

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Ignite-extensions repository structure

Alexey Goncharuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Ignite-extensions repository structure

Nikolay Izhikov-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Ignite-extensions repository structure

Alexey Goncharuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Ignite-extensions repository structure

Saikat Maitra
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
>