Some sort of "proposed final" state for 1.2 JavaOne

[David Blevins]

First, sorry can’t make the Tuesday call today as I’m flying, so maybe not so useful to add an agenda item and not be there to discuss, but want to at least raise it for list discussion.

On the Friday JWT call, we had a general feeling it would be good to delay a truly final state until after JavaOne so we could use JavaOne to get feedback before closing the lid on the JWT work.  Reason being, seems everyone who looks at it adds something significant and it’s getting better all the time.  Case in point, on Friday with the help of John Ament we now have the ability to inject primitive claims into @RequestScoped beans.

If we come to JavaOne with the lid closed, we’re putting ourselves in the position to have to reject a lot of feedback.  If we come with everything as ready as possible, but in some not quite final state we can still incorporate feedback and likely hook in more contributors.  One path we’re saying a lot of nos and pushing people away, the other we’re potentially saying a lot of yeses and pulling people in.

I’m not quite seeing the advantages of the nos — alternate perspectives would be great.  Open to thoughts and general discussion.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

[John D. Ament]

I personally would like to see us decouple the MP release line and the individual spec release lines.  It will help us achieve some of what's being asked here.  Specifically, if I can release 2-3 versions of a single spec within the span of the top level spec's release train, then I can deliver more functionality quickly and get feedback faster.  We would have smaller pieces done quickly that can go into user's hands and iterate on ideas quicker.  Some of the changes I'm seeing going in this release are massive, to the order that they're the same size as entire Java EE features.  I'm not convinced they're all useful to users and perhaps if we cut a smaller chunk, we may have value quicker.

We do have to figure out how to make some of these ancillary tasks less impactful and determine how to simplify our development strategy.  

[sst...@redhat.com]

My feeling is that we go forward with a time boxed approach and deliver the current set of APIs as the next final versions and iterate changes into the next MP versions.

Given that Java EE 8 is the main topic of J1, we will be most likely be moving to a new major MP 2.0 release, and there will be a lot of changes regardless of feedback, so there is not a long life to a 1.x version stream anyway.

[Ken Finnigan]

You raise some good points John, and figuring out how to separate spec and MP.io releases is something we haven't figured out yet it seems.

I also believe that we would be better served by each spec having their own release schedule or time-box, that may or may not align with other specs or even the top level MP.io

It would be great to reach a point where each spec could advance its releases as frequently as bugs or new features are required.

Then the MP.io rollup release becomes a case of choosing what's currently released for each spec.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/90dd90a3-3eec-4961-99b7-a448a9f97037%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Millidge]

I think we should release MP 1.2 on a timebox so if that's JavaOne then that's fine. I don't see that that stops feedback. Given we are going to iterate on a regular cadence then we won't be closed for feedback.

I agree with Ken that MP.io should have a regular cadence which is different to individual specs and just sweep up at release the current latest version of the individual specifications

On Tuesday, 5 September 2017 19:08:35 UTC+1, Ken Finnigan wrote:

You raise some good points John, and figuring out how to separate spec and MP.io releases is something we haven't figured out yet it seems.

I also believe that we would be better served by each spec having their own release schedule or time-box, that may or may not align with other specs or even the top level MP.io

It would be great to reach a point where each spec could advance its releases as frequently as bugs or new features are required.

Then the MP.io rollup release becomes a case of choosing what's currently released for each spec.

Ken

[Kevin Sutter]

I think most of my comments have already been raised by others...  I think by having something "real" by JavaOne is critical to getting feedback.  Commenting on JWT 1.0 or MP 1.2 is much easier than attempting to comment on something that is still baking.  We've stated since day one that we need to be more innovative and more iterative with our processes.  To that end, we can iterate again with feedback received at JavaOne to feed into JWT 1.x and/or MP 1.x.

Concerning the discussion about having more time to iterate on individual components before feeding into the next MP train...  I like that idea.  But, we've also stated we like time-boxed releases and we've talked about doing quarterly releases.  I know we didn't quite make that cut for 2017, but we came close.  If we only want to do two MP releases each year and then we just pick up what's ready in Mar and Sept (for example), that's fine.  But, to be quite honest, without the push of these MP releases, how many of the component releases would exist?  I think it's a give-and-take situation. 

Very happy to continue this discussion, but I'd like to close down on MP 1.2 before JavaOne.

Thanks, Kevin

[John D. Ament]

Kevin,

I think the big difference (at least in my head) is that the time boxed quarterly release is for the overall MP release.  That's why I've always pushed that its whatever is ready at that point in time as being the specs that ship in the release.

John

[Ondro Mihályi]

I wouldn't postpone whole MicroProfile release just to gather more feedback. But I also think that individual features should live and be developed separately on their own, and any MicroProfile release would just pick the latest final versions of the available features.

If there are some features we expect to have a valuable feedback during JavaOne I suggest that those features delay their final version until after J1 or release what's ready and plan for a new version immediately after J1. It may mean they miss the MP 1.2 release, but that isn't a problem. We need to think about releases of individual features and releases of MicroProfile separately.

So the following are valid scenarios for me:

 - a new final version of a feature is available before MP.next is released -> it becomes part of MP.next

 - the same situation (a final version is available), but there are serious concerns raised after the release -> it doesn't become part of MP.next and is simply skipped until concerns are addressed in the next version of the feature

 - an RC version of a feature exists but no final version yet -> several options

                    - release the last RC as final quickly to catch the next MP release train, in case of any concerns, the release is just skipped as described above

                    - simply miss the next MP train and plan for a later MP version. The RC can be presented at conferences or blogs to gather attention of reviewers 

                    - reduce the scope and revert some functionality that hasn't been reviewed and release a final version (again, it can be skipped for MP.next in case of concerns)

Based on my experience, a final version gathers a lot more attention and feedback than an "unfinished" release candidate. With our release cadence, any feedback can be addressed in future versions. That is unless there's a risk that addressing the feedback later would cause a significant backwards incompatibility. In that case, it's still worth to release a final version of a feature, but postpone its inclusion in MicroProfile to a later release. 

As an example, I suggest that JWT 1.0 is released before J1 to fuel the interest and feedback, but it's not included in MP 1.2 and rather postponed to a future MP release if there are some concerns.

--Ondro

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[sst...@redhat.com]

For JWT I don't see any major changes going into 1.0 as we will be starting a 2.0 effort after J1 to align with Java EE 8 and I expect to only be bring in what is essential to 1.0. My recommendation is to finalize 1.0 and incorporate feedback into 2.0.

[Alasdair Nottingham]

Hi,

I see JavaOne being critical for MicroProfile. Essentially in a year we have released 1 update to MicroProfile which is essentially config. I think we need to show something more complete and compelling. I agree getting feedback is good and we will get some at JavaOne, but I think we will get more, better feedback delivering something than holding off to get the feedback. As has been said we get better feedback on something final than something that isn’t. This sucks because you might do something wrong that you want to back away from, but I think we have said we would retain the option of making breaking changes if the need is high enough.

In terms of JWT I know I haven’t been on the call for the last few weeks due to vacation, but I think it looks pretty good and I agree with Scott that we should finalize it, get it into MP 1.2 and then iterate for in a new release. 

I think things will change post 1.2 because we have enough stuff to enable more independent iteration with the timeboxed iterations and we are familiar with how Eclipse works. I just think we need something that looks good to prove that MicroProfile is delivering on our promises from last year. I really think we need JWT to get into MP 1.2 because at JavaOne last year we said it would be simple to do, so I think it’ll look odd if it doesn’t make it.

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/393d94b0-c4b3-4585-a28b-f15fff4d5f23%40googlegroups.com.

[Mark Little]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/393d94b0-c4b3-4585-a28b-f15fff4d5f23%40googlegroups.com.

[Werner Keil]

Essentially most "stories" or feature requests are based on a collection of Microservice Patterns like this one: http://microservices.io/patterns/index.html

Not all of them are relevant to frameworks or libraries like MicroProfile, Dropwizard, etc. but most or all of the "infrastructure" layer are pretty important. That's where the current ones or those in good progress reside.

JavaOne last year was more like Martin Luther nailing his proclamations on the door of a church 500 years ago. It took him and his PR expert Lucas Cranach at least 5 more years to publish their first material. It would be good to show a few results just a year after the "proclamation" of MicroProfile even if it covers only 2 or 3 of those patterns. 

Werner

[Emily Jiang]

+1 Werner! I had a quick look at the pattern. MicroProfile 1.2 can certainly take quite a few boxes there.

+1 on most of comments on releasing Config 1.1, JWT, Fault Tolerance, Health Check and Metrics in MP 1.2. By the way, if we have other very big controversial feedback, we can always start a different spec. So far, MP 1.2 looks very rich and promising. Good work, Team!

Emily

[Mark Little]

I agree with getting 1.2 out and iterating over specs. We need to be more agile (small a) and I'd rather do things from JWT as it stands in n order to have it included so people can try it and give feedback (implementation driven experience, remember?) then add them back in later, than delay 1.2 or drop JWT entirely.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4fa551e7-9bf1-4e96-8e1d-60900ee21c4c%40googlegroups.com.

[Ian Robinson]

I agree with the many comments on demonstrating incremental progress. Thats what we set out to do in the beginning, a year ago, and our largest opportunity for feedback is JavaOne. So lets keep everything we've worked so hard to get this far, deliver it, and get feedback for the next release.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/90dd90a3-3eec-4961-99b7-a448a9f97037%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[David Blevins]

Sounds wildly unanimous and great points made.

Let’s definitely close 1.2 for JavaOne and center our message of “we can incorporate your feedback in MicroProfile 2.0”.  Our “feedback algorithm” then becomes, using JWT as an example:

  -  If we get a lot of feedback on JWT 1.0, we bump the version number to JWT 2.0.  We advertise a redesign.

  -  If we get minor feedback on JWT 1.0, we go to JWT 1.1

Let’s all also agree on the following.  If someone throws out an idea that requires a large change or redesign:

  - we do not say “too late for 1.x”.

  - we instead say “sounds like a great idea for 2.x!” 

With the first people hear both a “no” and “the fun was in the past”.  With the second, people hear “yes” and “the fun is just starting”.

If we can master that sales pitch, this is even better than a proposed final.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c23d95aa-32f8-4377-8e2e-b59616ed76ae%40googlegroups.com.

[sst...@redhat.com]

Well said.

[Mike Croft]

"Let’s definitely close 1.2 for JavaOne and center our message of “we can incorporate your feedback in MicroProfile 2.0”. "

Absolutely! We've got 2 angles on this messaging too - the specs we've pushed out for 1.2 AND specs which have repositories created but yet to get moving (OpenTracing, OpenAPI and REST client). It would be cool to invite interested people to throw in ideas for those if they're already users of Swagger or Zipkin or something and have experience to contribute :)

[Emily Jiang]

Sounds great!
Emily