Re: [VOTE] skip deployment of integration-test and samples artifacts

2022-02-14 Thread Francois Papon

+1

regards,

François

On 15/02/2022 08:01, Benjamin Marwell wrote:

Hello Shiro devs and users!

As discussed on the dev list, there seems to be a majority in favour
of not deploying integration tests and samples anymore.
The change is targeted to Shiro 2.0.0 and either Shiro 1.9.1 or 1.10.0.
It can be integrated in 1.9.0 as well if there is demand.
This vote does not target a specific version, though.

Please vote if you agree with this change or not.

Technical change:
Add the property true to
artifacts which are part of the integration tests and/or samples modules.

Rationale:
Those artifacts are usually only interesting for development (ITs) and
for reference used by other developers (samples).
Binary artifacts should not be needed for those, especially not on
maven central.

- [ ] +1 (fully agree)
- [ ] 0 (neutral)
- [ ] -1 (veto; please add a reason for your veto to make it count)

This vote will run for at least 72 hours and can be resolved by lazy
consensus. Rules of the Apache Foundation Voting Process [1] apply
where not stated otherwise.

Thank you all for your participation!

- Ben

--

- [1]: https://www.apache.org/foundation/voting.html


[VOTE] skip deployment of integration-test and samples artifacts

2022-02-14 Thread Benjamin Marwell
Hello Shiro devs and users!

As discussed on the dev list, there seems to be a majority in favour
of not deploying integration tests and samples anymore.
The change is targeted to Shiro 2.0.0 and either Shiro 1.9.1 or 1.10.0.
It can be integrated in 1.9.0 as well if there is demand.
This vote does not target a specific version, though.

Please vote if you agree with this change or not.

Technical change:
Add the property true to
artifacts which are part of the integration tests and/or samples modules.

Rationale:
Those artifacts are usually only interesting for development (ITs) and
for reference used by other developers (samples).
Binary artifacts should not be needed for those, especially not on
maven central.

- [ ] +1 (fully agree)
- [ ] 0 (neutral)
- [ ] -1 (veto; please add a reason for your veto to make it count)

This vote will run for at least 72 hours and can be resolved by lazy
consensus. Rules of the Apache Foundation Voting Process [1] apply
where not stated otherwise.

Thank you all for your participation!

- Ben

--

- [1]: https://www.apache.org/foundation/voting.html


Re: [DISCUSS] Not deploying specific artifacts?

2022-02-14 Thread Benjamin Marwell
Thanks, I will start a code vote on the dev and user list then! :)

Am Di., 15. Feb. 2022 um 05:15 Uhr schrieb Jean-Baptiste Onofré
:
>
> +1
>
> It sounds good to me.
>
> Regards
> JB
>
> On Mon, Feb 14, 2022 at 12:28 PM Benjamin Marwell  wrote:
> >
> > Hi all!
> >
> > Looking at the deploy/upload times and the usage stats,
> > not deploying some of the modules might be a good idea.
> >
> > We could set maven.deploy.skip=true for some modules, especially:
> >
> > * integration tests
> > * samples
> >
> > Those artifacts are usually only interesting for development (ITs) and
> > for reference used by other developers (samples).
> > Binary artifacts should not be needed for those, especially not on
> > maven central.
> >
> > Please add your opinion here.
> >
> > - Ben


Re: [DISCUSS] Not deploying specific artifacts?

2022-02-14 Thread Jean-Baptiste Onofré
+1

It sounds good to me.

Regards
JB

On Mon, Feb 14, 2022 at 12:28 PM Benjamin Marwell  wrote:
>
> Hi all!
>
> Looking at the deploy/upload times and the usage stats,
> not deploying some of the modules might be a good idea.
>
> We could set maven.deploy.skip=true for some modules, especially:
>
> * integration tests
> * samples
>
> Those artifacts are usually only interesting for development (ITs) and
> for reference used by other developers (samples).
> Binary artifacts should not be needed for those, especially not on
> maven central.
>
> Please add your opinion here.
>
> - Ben


[GitHub] [shiro-site] bdemers commented on a change in pull request #150: [SHIRO-866] 1.9.0 update and announcement

2022-02-14 Thread GitBox


bdemers commented on a change in pull request #150:
URL: https://github.com/apache/shiro-site/pull/150#discussion_r806092807



##
File path: CONTRIBUTING.adoc
##
@@ -11,13 +30,14 @@ Git will automatically convert line endings for you.
 
 === Changes to link:data/releases.yaml[]
 
-* If the new `latestRelease` is a new minor release (e.g. `1.x.0`), prepend 
the old version to the `oldReleases` array. +
-Please skip this step for minor releases.
-* If the new `latestRelease` is a minor release, update the version number of 
the `releases` object at the end of the file. +
-_Rationale:_ Every minor release should only be represented with the latest 
bugfix release.
 * Change `latestRelease: "..."` to the new version.
 * Update the `versionInfo` object accordingly. +
 You can just add a new release, there is no need to remove old releases.
+* Update the `oldReleases`/`releases` variable like so:
+** If the new `latestRelease` is a new minor release (e.g. `1.n.0`, where `n` 
is the new minor release version), prepend the old version to the `oldReleases` 
array. +
+Also add it to the 'releases' object at the end of the file as `1nx`.
+** If the new `latestRelease` is a bugfix release (e.g. `1.n.x`), update the 
version number of the `releases` object at the end of the file. +
+_Rationale:_ Every minor release should only be represented with the latest 
bugfix release.

Review comment:
   ```suggestion
   * Update the `oldReleases`/`releases` variable:
   ** If the new `latestRelease` is a new minor release (e.g. `1.n.0`, where 
`n` is the new minor release version), prepend the old version to the 
`oldReleases` array. +
   Also, add it to the 'releases' object at the end of the file as `1nx`.
   ** If the new `latestRelease` is a bugfix release (e.g. `1.n.x`), update the 
version number of the `releases` object at the end of the file. +
   _Rationale:_ Every minor release should only be represented with the latest 
bugfix release.
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@shiro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




Re: [DISCUSS] Not deploying specific artifacts?

2022-02-14 Thread Brian Demers
+1 !!


On Mon, Feb 14, 2022 at 6:29 AM Benjamin Marwell 
wrote:

> Hi all!
>
> Looking at the deploy/upload times and the usage stats,
> not deploying some of the modules might be a good idea.
>
> We could set maven.deploy.skip=true for some modules, especially:
>
> * integration tests
> * samples
>
> Those artifacts are usually only interesting for development (ITs) and
> for reference used by other developers (samples).
> Binary artifacts should not be needed for those, especially not on
> maven central.
>
> Please add your opinion here.
>
> - Ben
>


[DISCUSS] Not deploying specific artifacts?

2022-02-14 Thread Benjamin Marwell
Hi all!

Looking at the deploy/upload times and the usage stats,
not deploying some of the modules might be a good idea.

We could set maven.deploy.skip=true for some modules, especially:

* integration tests
* samples

Those artifacts are usually only interesting for development (ITs) and
for reference used by other developers (samples).
Binary artifacts should not be needed for those, especially not on
maven central.

Please add your opinion here.

- Ben


[GitHub] [shiro-site] bmarwell opened a new pull request #150: [SHIRO-866] 1.9.0 update and announcement

2022-02-14 Thread GitBox


bmarwell opened a new pull request #150:
URL: https://github.com/apache/shiro-site/pull/150


   fixes [SHIRO-866](https://issues.apache.org/jira/browse/SHIRO-866).
   
   @fpapon the date is set to this friday (2022-02-18).
   We will probably need to change this, alone for the 72h vote cycle.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@shiro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org