OK:
· I’ve
removed the release date
· We
keep “PolarSys IDE 0.8” because we’ve started to communicate
with it
· But
next time, for the community, it will be better to use an
increment of third segment
Thank
you,
Benoît
You don't have
to rename it to 0.7.1. I said that this is *typically* the
case with service releases.
I recognise that this is a little different from a service
release.
If you feel that the version number should be 0.8, then you
can use that version number.
I recommend that you capture as much information about the
release as possible in the release record. This will help
adopters understand.
We *can* create a review if you think the project would
benefit from the extra exposure. But there is not requirement
to do so.
HTH,
Wayne
On 02/24/2014 12:26 PM, LANGLOIS Benoit
wrote:
You
mean that “PolarSys IDE 0.7.1” should be better. It’s true
that we had the question “What’s the difference with
PolarSys IDE 0.7?”.
Then,
I guess that:
·
We
rename “PolarSys IDE 0.8” in “PolarSys IDE 0.7.1”
·
We
keep a release documentation to trace the release with its
differences
·
No
release review is required
Thanks,
Benoît
On 02/24/2014 11:09 AM, LANGLOIS Benoit
wrote:
1.
Plugins and features are still the same, except that we
changed the PolarSys IDE version number. Do we need to
submit an IP log?
No. If there are no actual intellectual
property changes, then a new IP Log is not required.
2.
Can we submit a review documentation even if we don’t have
the version number of the aggregated components?
Strictly speaking, this sounds very
similar conceptually to a "service release" (AKA "bugfix"
release). There are no significant new features, and no new
IP. According to the EDP, no review is required.
Service releases are typically denoted by an increment of
third segment, but there is no specific rule that requires
this.
The project may benefit from the extra exposure that comes
with a review, so you may want to consider doing one anyway.
But it's up to you.
Wayne
