Major Release Bump and Breaking API Changes for ShrinkWrap 2.0

dev
#1

With the advent of containerized builds, we’re in a position to do away with “build on someone’s machine and use that binary as official releases”. We can go to an authoritative build server that builds in a known, auditable, containerized environment.

To accomplish this at present we need 2 versions of Java; JDK6 to build and JRE5 to run the tests (ShrinkWrap is JRE5+ compatible at the moment). Making a container with these versions is difficult because of distribution rights; OpenJDK wasn’t even available until version 6.

As it’s now 2016, we may consider a proposal to make a new major release of ShrinkWrap, break compatibility with JRE5+, and refactor some things. Some version usage data:

https://plumbr.eu/blog/java/java-version-and-vendor-data-analyzed-2016-edition

Remember that ShrinkWrap is a lower-level library and must stay focused on mass adoption. Using cutting-edge JDKs is not a priority, but we need to find a good balance. ShrinkWrap, as always, will keep its 0 dependencies on runtime libraries aside from the Java APIs.

  1. Do we want to consider a major version bump? This will signal the first time we’re allowed to break APIs since 2009, so if we do it once, we do it right.
  2. What JDK version to base atop?
  3. What other API changes do we want to make?

S,
ALR

#2

I think it makes sense for a major version bump, and to use JDK 7 as a base.

Though JDK 6 still has nearly 10% usage in 2016, it’s down from 20% in 2015. To me that indicates that 2017 could see a drop of JDK 6 usage down to 5% or less.

In terms of API changes, we might want to consider including some of the Shrinkwrap things we’ve done in WF Swarm for inclusion.

Ken

#3

Though JDK 6 still has nearly 10% usage in 2016, it’s down from 20% in 2015. To me that indicates that 2017 could see a drop of JDK 6 usage down to 5% or less.

Sure, and JDK7 would make some things easier for us, for instance moving the nio2 stuff into ShrinkWrap core. But I’m concerned for what’s in the broader Arquillian ecosystem that may not have moved to Java7 yet, so will be looking forward to Aslak’s (and the rest of the community) opinion on that.

In terms of API changes, we might want to consider including some of the Shrinkwrap things we’ve done in WF Swarm for inclusion.

Have you added stuff or changed them? Additions, if relevant to the general ShrinkWrap audience, are always valid for consideration with a minor version bump.

S,
ALR

#4

We’ve added some different Archive types, particularly a JAXRSArchive.

I think most of the changes were modifying existing JAR and WAR Archive behavior. Would need to spend some time looking again, but maybe it needs a way to customize behavior without having to create a new Archive type.
As some of the things we do are likely only applicable to WF Swarm

Ken

#5

maybe it needs a way to customize behavior without having to create a new Archive type.

Cool extensibility feature!

#6
  1. Yes, but I’m not sure how many changes would occur in API.
  2. 1.7
  3. completely agree with the Ken’s proposal - way to customize behavior without having to create a new Archive type

Arquillian-core still supports Java 5 :slight_smile:. I would definitely vote for upgrading to newer Java version and leaving the archaic ones. But if we did it, we should do it for arquillian-core as well, so there would be similar questions for arquililan-core:

  1. Do we want to consider a major version bump? What version should we choose? 1.2.0 or 2.0.0?
  2. What other API changes do we want to make?

Matous

#7
  1. Do we want to consider a major version bump? What version should we choose? 1.2.0 or 2.0.0?

Breaking back-compat means we need to go to 2.0.0. Which is also an opportunity to revise/break other APIs we don’t want to carry for the next 7 years.

#8

I’ve started some work here, requiring JRE8+.

https://github.com/ALRubinger/shrinkwrap/commits/2.0.0-X

Also note I’ve opened up “Issues” on GitHub for 2.x work only; likely it makes sense to retire the JIRA instance for 1.x stuff only; WDYT?

S,
ALR

#9

Updated the work and have a POC for review and action plan proposed: