[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
> On 30 Jul 2020, at 17:33, Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> wrote:
>
>> if I do it now, I'll either miss all future changes that might occur to cpp, or have to redo the whole thing again and again. not a joy.
> The only way I see to resolve it is to add the embed-cdt package to the EPP project.
If this will simplify maintenance, sure, let's do it.
Please take a look at https://github.com/gnu-mcu-eclipse/org.eclipse.epp.packages and compare the embed-cdt branch with the 2020-06_R tag.
You'll see that it adds 3 folders with the embed-cdt product, but there are also some small tweaks.
I personally don't know how to accommodate these tweaks in the main epp repo.
And the code that requires continuous updates to match the cpp product is in the 3 new folders, I don't see how having them in the EPP project simplifies maintenance, unless we find a way to use common definitions for both embed-cdt and cpp products.
>>>> And how can I create the release record for the next release when I don't know what changes will be included, so what will be the version number?
>>> The only thing that you need to decide is: would you consider breaking changes for the next release or not.
>> ah, I know the semantics of the version numbers, but how can I tell if the changes are breaking compatibility, if they are enhancements or bug fixes?
> It is very formal and partially automated by Tycho for the Java API that you bundles provide. Of cause we always can find corner cases, when actual compatibility is broken by "one byte change". But you always (OK, almost always) know which change is compatible.
Hmmm... I definitely failed to express my question correctly. :-(
I **do know** which changes break compatibility, which are enhancements and which are bug fixes, I don't need any Tycho to tell me.
Just that I know this only **after** I implement the changes, I cannot tell **now** what impact will have the changes done as a result of a bug report that will come **tomorrow**, or any time in the future, so I cannot plan for it.
>> unless the Eclipse Foundation has a crystal ball to tell the future, I personally have no idea what changes will come with the next release.
> This is a kind of commitment. I do not see anything bad in this commitment as downstream functionality should be aware of what to wait from the project.
You're probably right, but I don't know what this means in practical terms.
> If you plan a release in 2020-09 with no breaking changes - then no breaking changes should be included for 2020-09.
This seems an arbitrary choice for me.
I can plan for anything I am aware of, but I cannot plan for events that will occur in the future, all I can do is to delay their implementation until better days, but some issues may be urgent.
Regards,
Liviu
