Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nebula-dev] CDateTime version update?

The Eclipse Development Process has no notion of incubating *components*.

In fact, the EDP has no formal notion of component; notions of separate components within a mature project that are "incubating", "interim", "experimental" or whatever are project-specific notions.

A project can consume any bits that have been *released* by another project.

Permanent incubators, like the Nebula Incubator project cannot not do releases.

So... if you're talking about a component that's from a release version of mature projects Nebula or NatTable, then the EDP considers you good-to-go.

If you're talking about a component from the Nebula Incubator, you can't use it in another project's release until it's moved into the parent project and included in a release.

For completeness, you can include released code from a project in the incubation phase, but the consuming components would have to conform to the incubation branding requirements.

Does this make sense?

Wayne



On 04/05/16 05:42 AM, Wim Jongman wrote:
We are waiting on Wayne/EMO to respond.

Wayne/EMO:

* can release train projects consume incubation components from Nebula?
* If so, is there a restriction on the version number that these components must have e.g => 1.0.0?





On Wed, May 4, 2016 at 10:02 AM, Dirk Fauth <dirk.fauth@xxxxxxxxx> wrote:

Hi,

Any opinions or information on that topic? Does anybody care?

Greez,
Dirk

Am 29.04.2016 11:24 schrieb "Wim Jongman" <wim.jongman@xxxxxxxxx>:
cc-ing Wayne for comments.

Wayne:

* can release train projects consume incubation components from Nebula?
* If so, is there a restriction on the version number that these components must have?

Dirk:

Normally the major version number is bumped when the API changes. However I am not sure if this rule also applies when going from 0.x.x to 1.0.0

When people consume a component they normally restrict the version number in that API range e.g. [0.0.0 1.0.0) (square bracket is inclusive and round bracket is exclusive). This means that peoples build would break when we do this.

The Stable widgets all deserve to go to version 1 if they are not yet.

I am not comfortable bumping the version number just to "make people feel good" or comply to some companies internal rules about version numbers. However, I also not want to block it.

Are there other opinions in the list?

Cheers,

Wim



On Thu, Apr 28, 2016 at 8:57 PM, Dirk Fauth <dirk.fauth@xxxxxxxxx> wrote:
Hi Nebula Team,

I have a question regarding the version policy of our "released" widgets. In detail I'm talking about the CDateTime widget.

I created a NatTable editor based on CDateTime because the SWT DateTime control has several issues. There I realized that CDateTime is published with version 0.14.0. CDateTime also has a dependency to CWT which is published with version 0.9.0.

I just learned that there are release rules regarding the usage of plugins in incubation state. While of course Nebula as project is in incubation, people assume that the released widgets with a version >= 1.0.0 are stable and mature. But plugins with a version < 1.0.0 is still seen as incubation/unstable and therefore not allowed to use it within projects in the release train.

Honestly I'm not sure about that rules and NatTable is not part of the release train. But NatTable is consumed by projects in the release train. Now if NatTable breaks the release rules by consuming incubation plugins, it would affect these projects too.

There hasn't been a lot of activity in these two projects, despite some cleanups a few months ago.

I would like to bump the versions of these two projects to 1.0.0, so I am able to release a NatTable editor based on CDateTime without introducing issues to other release projects.

Are there any objections regarding such an update?

Greez,
Dirk

_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/nebula-dev


_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/nebula-dev

_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/nebula-dev


--
Wayne Beaton on behalf of the Eclipse Management Organization
@waynebeaton
The Eclipse Foundation
EclipseCon
          France 2016

Back to the top