search

arquillian / arquillian-universe-bom

'Bill Of Material' Maven artifacts for a simplified view of the Arquillian Universe
Apache License 2.0
13 stars 12 forks source link

Stable vs Latest arquillian-universe stack #3

Open aslakknutsen opened 9 years ago

aslakknutsen commented 9 years ago

The current version we have in master branch is just a selection of the latest versions of all modules. We have no proof that any of this actually works at the moment ;)

Maybe we should consider two 'branches' of this bom, one that is considered stable and one with the absolute latests.

?

lordofthejars commented 9 years ago

We could do this, something like edge and stable, the problem is that then let's start a release train of several components like APE, Cube, ... that are alpha from their initials.

smiklosovic commented 8 years ago

I think that we should get rid of alphas where it is possible and be more -final release oriented. Some projects have very long release cycle. They are verified to work in real life but a developer feels that it is not mature enough to cut some final release.

I did this with Governor, Recorder and Droidium, the next recorder will be 1.1.0.Final and Droidium of 1.0.1.Final with tons of version bumps and minor fixes is on the way soon. Only waiting for Graphene 2.1.0.ALPHA3 :)

@lfryc why it can not be released as 2.1.0.Final? What is the logic behind it?

Same holds e.g. for Spacelift which is of version alpha8 currently and that is ridiculous to me. It seems like we are very very hesitant to do final releases and it is quite suspicious that it took us 8 releases and we are still on alpha ... I am using that project heavilly not only in Arquillian context and nothing seems to block it from final. That project is already mature enough to me. I know that @kpiwko does have some API ideas which wait to be implemented but I would not hesitate to call it -final as of now at all.

Even this is hard to enforce in the comunity, it would be worth to it to look over the Arquillian platform and do something about alphas. If something is of alpha version, it looks for people like it is hardly usable and may change significantly in the future which is not the truth for a lot of cases.

@aslakknutsen

how do you want to do the verification of the supposed-to-be working components? It seems to me that the testing matrix would be huge.

smiklosovic commented 8 years ago

One additional note.

I am about to release Droidium 1.0.1.Final and I am depending on Spacelift Alpha8, Graphene 2.1.0.Alpha3, Drone 2.0.0.Alpha5 and these projects are using Selenium 2.47.1 (there is already newer version of it).

Droidium uses Selendroid of version 0.16.0 which uses Selenium 2.45.0 and it depends on Drone of 2.0.0.Alpha5.

For the compatibility, I would downgrade Selenium to 2.45.0 for Drone and Graphene, cut Drone 2.0.0.Final and Graphene 2.1.0.Final and I would release Droidium 1.0.1.Final which uses Selendroid of 0.16.0 with Selenium 2.45.0.

Another option is to persuade Selendroid guys to release 0.17.0 with Selenium 2.47.x.

I am not sure what is better but I just want to let you know that I would be very happy to have these releases aligned so finals depend on finals as it is supposed to be.

Next thing is that after this final release of Droidium, I want to leave it for quite a long time idle again and return to it possibly in the future so having one complex solution build on -finals is very sound to me and it sells good as well.

//cc @MatousJobanek

lordofthejars commented 8 years ago

I agree with @smiklosovic I think we should do something like Eclipse. Create some milestones every 6 months, and every that period all projects that are Alpha (and we know they are not so buggy) should go to final and release everything. If in the middle some component has released a final version then it is not a problem at that date the latest version is going to be included in the train release. If in the future we need to change public API then we change it and that's all because at the end we would do the same in case of Alpha ones.

smiklosovic commented 8 years ago

I am taking back my point about downgrading. According to @MatousJobanek I can use whatever Selenium I want in my projects - but the fact is that I need to override it on my side which is uncomfortable but viable and valid option.

However, the desire that all these releases are finals still holds.

aslakknutsen commented 8 years ago

That's where the universe comes in tho. To downgrade/upgrade so the components match across the universe. Selenium is a bit special as it seems to require a new version every time a browser does a minor release.. Which is a bit random and outside of our control.

aslakknutsen commented 8 years ago

how do you want to do the verification of the supposed-to-be working components? It seems to me that the testing matrix would be huge.

Yes, it would wouldn't it :)

I'm not foreseeing a 100% test coverage over all modules in all combinations. But I think at least a few strategic 'smoke' tests would be a good beginning.

We have the showcase:universe tests that I've been playing with so far that is catching a few integration issues: https://github.com/arquillian/arquillian-showcase/commit/d5a261abcce6b477e39dddb5297d4a7fae2943fe

If we split that up a little bit so we can run just very specific bits of, e.g.:

Then we can also choose to do a run with 'all profiles' enabled to see if any of the modules override some of the others etc in a bad way.