Community
Participate
Working Groups
We have an automated test to validate the update path from 3.5 to 3.6, we should change it to test the update from 3.6 to 3.7
The 3.5->3.6 test has been failing lately so I have disabled it in the 3.7 stream. Since it didn't exercise any 3.7 stream code it was not useful as a regression test.
Is there any value is keeping the 3.5 to 3.6, or maybe even 3.5 all the way to 3.7?
(In reply to comment #2) > Is there any value is keeping the 3.5 to 3.6, or maybe even 3.5 all the way to > 3.7? Testing the exact same scenario - upgrade from 3.5.0 to 3.6.0 - every time we perform a 3.7 build does not add any value. The most interesting case is ensuring we can upgrade to our latest 3.7 build, to ensure we don't introduce incompatibilities in our metadata that prevent this from occurring. We could actually test 3.5->3.7 but I think the mainline scenario is 3.6->3.7 as we expect this to be the most common operation for our users. Upgrade across multiple releases, such as 3.5->3.7, should work because we haven't introduced any breaking changes, but I don't see that as being a critical requirement to support.
(In reply to comment #3) > We could actually test 3.5->3.7 but I think the mainline scenario is 3.6->3.7 > as we expect this to be the most common operation for our users. Upgrade across > multiple releases, such as 3.5->3.7, should work because we haven't introduced > any breaking changes, but I don't see that as being a critical requirement to > support. Yeah, I was wondering if there was any chance we could release something that would be incompatible with 3.5, but somehow work with 3.6? In this case the 3.5 -> current would be interesting.
(In reply to comment #4) > Yeah, I was wondering if there was any chance we could release something that > would be incompatible with 3.5, but somehow work with 3.6? In this case the > 3.5 -> current would be interesting. Yes it is certainly possible. For example we added various metadata concepts in 3.6 (expression language, negation, etc). If 3.7 started to leverage this new metadata, then 3.5 would not understand it. However that might be an acceptable tradeoff if we do decide to use these concepts.
If you intend to go ahead with the change, there are corresponding modifications needed in the releng build. The build currently fetches the 3.5 binaries and copies them to the test machines and creates a property file specifying their location. This will have to be updated to specify 3.6 files.
Setting a milestone as I believe that this is very important to ensure and we need to do it sooner rather than later.
Kim, I am working on updating these tests. Could you please look at what changes we will need to make in the builder/test framework? Thanks.
Created attachment 186644 [details] patch for p2.tests
The builder should be fine. I see you are just installing from repos. DJ you can release this patch and I can run a test build for these tests only.
I'm installing from repos but will need a copy of the 3.6 platform binary as a starting point on the test machines. Similar to how we set up "org.eclipse.equinox.p2.reconciler.tests.35.platform.archive", we'll also need to set the "org.eclipse.equinox.p2.reconciler.tests.36.platform.archive" System property.
I have the following specified in equinoxp2tests.properties org.eclipse.equinox.p2.reconciler.tests.lastrelease.platform.archive.linux org.eclipse.equinox.p2.reconciler.tests.lastrelease.platform.archive.macosx org.eclipse.equinox.p2.reconciler.tests.lastrelease.platform.archive.windows I changed it to lastrelease so I don't have to update the version every release. I also use this archive to invoke the director to install the JUnit test bundles from the test repo.
Created attachment 187156 [details] patch
Patch released.
We've had problems with this test the past couple of nights: Linux - getting the following errors: Initializing 3.6 to get the profile paths properly setup.: java.io.IOException: Cannot run program "/tmp/1295592166847-0.21108675401970745/eclipse/eclipse" (in directory "/tmp/1295592166847-0.21108675401970745"): java.io.IOException: error=2, No such file or directory MacOS - test passes Win - Test DNF I've added some debugging to the test suites to hopefully help us find out what the problem is. Specifically since the error is that we can't run the exe, I've added checks after we extract the platform binary to check and see if the exe exists.
Looks like the platform binary zips were 0 length on the test machines. Kim is going to fix it. Closing.
The files were 0 length on the linux machines (kim has fixed it) and I think the windows problems were issues with the tests themselves which I have fixed.
