Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

roadmap chart #251

Open
wants to merge 23 commits into
base: master
from

Conversation

@Tibor17
Copy link
Contributor

Tibor17 commented Nov 3, 2019

No description provided.

@asfgit asfgit force-pushed the milestones-roadmap branch from 2c56c29 to 8ec315b Nov 4, 2019
@Tibor17

This comment has been minimized.

Copy link
Contributor Author

Tibor17 commented Nov 4, 2019

@jon-bell
@Col-E
You are welcome to participate as well.

@eolivelli

This comment has been minimized.

Copy link

eolivelli commented Nov 4, 2019

@Tibor17
is it really necessary to publish such roadmap?
We can have JIRAs and assign them to a version.

So we need to share it explicitly on dev@ list?

That said for me it is okay, I am just asking

@Tibor17

This comment has been minimized.

Copy link
Contributor Author

Tibor17 commented Nov 4, 2019

@Tibor17
is it really necessary to publish such roadmap?

Maybe it is important for contributors/devs because some people at the U.S. Universities found Surefire as an interesting project and they started similar activities by themselves that we have in this plan too. And it was a perfect match because we left their activity with Shell scripting and started contributing to Surefire because our plan really targets their research problem at the University.

So now the contributors can see if they fit, and if not then we can include them.

Our goal with @krosenvold @agudian is to put the extensions in Test List Processor and break backwards compatibility with system properties of config parameters (means added prefix: surefire. and failsafe.).
If you know these three things, as the Surefire internals (code and req extentions) and user req (like -Dtest=org.asf.MyTest over -Dtest=org/asf/MyTest.java) and the path of JUnit5, then you must see that our internal code and documentation should change (more inside and less outside) and this is possible only in major version.
With this plan we do not break anything till the end and we satisfy our internal req and users too.
Therefore this is on GH because the dvelopers can immediately see what changed in the history of road map and what code changed for the road map.
I do not see ML as a benefit in this special case because our contrinutors notice usually the most recent email in ML and not the diff.

We can have JIRAs and assign them to a version.

I want to have this work done in Jira of course but we need to find the time slot to do it.
Maybe you would help if you like to.

Tibor17 and others added 22 commits Nov 3, 2019
…aven.cli.transfer.Slf4jMavenTransferListener=warn
…n.cli.transfer.Slf4jMavenTransferListener=warn
…dependency in "surefire-extensions-api" and "maven-surefire-common"
…dependency in "surefire-extensions-api" and "maven-surefire-common"
…ava.specification.version}</maven.compiler.release>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.