You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we are going to make breaking changes can we do the following:
Release a 1.x version on ev3dev-stretch that includes 06ae05f - this should get OpenRoberta working on stretch - it is currently broken (someone just asked about this on IRC this morning).
Rename the root namespace and package names so that 1.x and 2.x can be installed in parallel (e.g. ev3dev > ev3dev2). This way, 2.x can be released so people can use it and OpenRoberta can keep working without constant maintenance while 2.x stabilizes.
It doesn't have to be the root namespace, but if both version are installed at the same time there has to be something different in the namespace, does there not? Otherwise, how would imports work?
I'd appreciate if we keep things stable for jessie. If we break things for stretch anyway I'll need to do some porting and depend on the right version. So please collect a list of things that are changed.
@ddemidov: If you rename the v1.x package and/or namespace, it breaks OpenRoberta, which defeats the purpose of trying to not break it. I like just adding a 2 to the names (instead of -v2), like you can have gtk2 and gtk3 installed at the same time or qt4 and qt5 installed at the same time. It is a common pattern in Linux.
@ensonic: I don't think there are any plans to make an breaking changes in ev3dev-jessie. The discussion here is the possibility of having parallel 1.x and 2.x versions in ev3dev-stretch so that OpenRoberta will keep working in ev3dev-stretch by using the 1.x version without you having to keep up with breaking changes in the 2.x version.
@dlech if it is not too much of a hassle having both api version installable in parallel would be great of course.
I think it would also be fair to then tell people that the new development happens on v2 and v1 is maybe getting a few patches for a while to keep it working (if needed). Sounds like a plan to me.
@dlech, I am trying to create stretch packages. Do I understand correctly that I need to do OS=debian ARCH=amd64 DIST=stretch pbuilder-ev3dev base (instead of OS=debian ARCH=amd64 DIST=jessie pbuilder-ev3dev base)? The command gives me
E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
W: Aborting with an error
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build/6468 and its subdirectories
I upgraded both the host machine (virtual image of Ubuntu 16.04.3 LTS) and pbuilder-ev3dev package. I am still getting
E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
when I do OS=debian ARCH=amd64 DIST=stretch pbuilder-ev3dev base. I do have gnupg and gnupg2 installed on Ubuntu though. @dlech, perhaps you have something in .pbuilderrc (mine is empty)? Do I need to add anything to archive list for stretch to work?
@ddemidov@dlech Can you open a new issue to discuss the packaging problems? I want to keep this thread clear so we can use it to track the list of breaking changes.
AFAIK, the only place where we haven't done a true EV3-G mapping is for LEDs, and in that case I think our API is the better form anyway for Python code. So I don't believe that there are any outstanding tasks for enabling the new base API surfaces. That being said, we do have issues open for other API sets which we'd like to implement.
Over the past week or two I've tagged things which I think are next on the to-do list with a 2.1 milestone (I just took a guess at a version number which seemed reasonable, it can be renamed) so we can get a sense of what would be immediately helpful.
Activity
dlech commentedon Sep 26, 2017
If we are going to make breaking changes can we do the following:
ev3dev>ev3dev2). This way, 2.x can be released so people can use it and OpenRoberta can keep working without constant maintenance while 2.x stabilizes.ddemidov commentedon Sep 26, 2017
For reference: #339 (comment)
ddemidov commentedon Sep 26, 2017
I understand the package name change, but why the root namespace?
dlech commentedon Sep 26, 2017
It doesn't have to be the root namespace, but if both version are installed at the same time there has to be something different in the namespace, does there not? Otherwise, how would imports work?
dwalton76 commentedon Sep 29, 2017
auto_modefor Sensors has been removeddwalton76 commentedon Oct 1, 2017
For
InfraredSensorwe changed the following namesred_upis nowtop_leftred_downis nowbottom_leftblue_upis nowtop_rightblue_downis nowbottom_rightand the
on_red_up, etc handlers now support multiple channels and are namedon_channel1_top_left, etcdwalton76 commentedon Oct 4, 2017
Importing core.py and auto.py will no longer work
ddemidov commentedon Oct 5, 2017
Which is better: rename stable package (and namespace) for OpenRoberta to
ev3dev-v1orev3dev-jessie, or rename future packages toev3dev-v2?ensonic commentedon Oct 5, 2017
I'd appreciate if we keep things stable for jessie. If we break things for stretch anyway I'll need to do some porting and depend on the right version. So please collect a list of things that are changed.
dwalton76 commentedon Oct 5, 2017
Can we keep just one package name but with different versions?
WasabiFan commentedon Oct 5, 2017
@ensonic see above. This thread is devoted to tracking breaking changes to make sure we can adequately document it.
ddemidov commentedon Oct 5, 2017
@dwalton76, see #381 (comment)
dlech commentedon Oct 5, 2017
@ddemidov: If you rename the v1.x package and/or namespace, it breaks OpenRoberta, which defeats the purpose of trying to not break it. I like just adding a
2to the names (instead of-v2), like you can havegtk2andgtk3installed at the same time orqt4andqt5installed at the same time. It is a common pattern in Linux.@ensonic: I don't think there are any plans to make an breaking changes in ev3dev-jessie. The discussion here is the possibility of having parallel 1.x and 2.x versions in ev3dev-stretch so that OpenRoberta will keep working in ev3dev-stretch by using the 1.x version without you having to keep up with breaking changes in the 2.x version.
ensonic commentedon Oct 5, 2017
@dlech if it is not too much of a hassle having both api version installable in parallel would be great of course.
I think it would also be fair to then tell people that the new development happens on v2 and v1 is maybe getting a few patches for a while to keep it working (if needed). Sounds like a plan to me.
ddemidov commentedon Oct 5, 2017
I'll try to publish stable version compatible with stretch tomorrow.
1 remaining item
ddemidov commentedon Oct 9, 2017
@dlech, I am trying to create stretch packages. Do I understand correctly that I need to do
OS=debian ARCH=amd64 DIST=stretch pbuilder-ev3dev base(instead ofOS=debian ARCH=amd64 DIST=jessie pbuilder-ev3dev base)? The command gives medlech commentedon Oct 9, 2017
The command looks correct. It seems odd that you wouldn't have gnupg installed. Have you tried installing it?
ddemidov commentedon Oct 9, 2017
But that is on my host system. I thought the error comes from withing pbuilder environment. Also, the command with
DIST=jessiedoes work.dlech commentedon Oct 10, 2017
I use
pbuilder-ev3devall the time with stretch, so I'm not sure what the difference would be (unlesspbuilder-ev3devneeds to be upgraded?).ddemidov commentedon Oct 12, 2017
I upgraded both the host machine (virtual image of Ubuntu 16.04.3 LTS) and pbuilder-ev3dev package. I am still getting
when I do
OS=debian ARCH=amd64 DIST=stretch pbuilder-ev3dev base. I do havegnupgandgnupg2installed on Ubuntu though. @dlech, perhaps you have something in.pbuilderrc(mine is empty)? Do I need to add anything to archive list for stretch to work?ddemidov commentedon Oct 12, 2017
pbulder.log
Here is the complete log of
OS=debian ARCH=amd64 DIST=stretch pbuilder-ev3dev base.dwalton76 commentedon Oct 12, 2017
The
Screenclass is now calledDisplay, this was done to match the EV3-G API 1:1WasabiFan commentedon Oct 12, 2017
@ddemidov @dlech Can you open a new issue to discuss the packaging problems? I want to keep this thread clear so we can use it to track the list of breaking changes.
ddemidov commentedon Oct 13, 2017
Or we could use #400.
WasabiFan commentedon Nov 16, 2017
Breaking change: Sound-related methods now take time in seconds (#431)
dwalton76 commentedon Aug 6, 2018
@WasabiFan did we have anything left to do for the new API?
WasabiFan commentedon Aug 6, 2018
AFAIK, the only place where we haven't done a true EV3-G mapping is for LEDs, and in that case I think our API is the better form anyway for Python code. So I don't believe that there are any outstanding tasks for enabling the new base API surfaces. That being said, we do have issues open for other API sets which we'd like to implement.
WasabiFan commentedon Aug 6, 2018
Over the past week or two I've tagged things which I think are next on the to-do list with a
2.1milestone (I just took a guess at a version number which seemed reasonable, it can be renamed) so we can get a sense of what would be immediately helpful.WasabiFan commentedon Dec 19, 2018
Closing as I believe this has been addressed. Please reopen if needed.