> > effort has cost me considerable time that could have been use
> elsewhere.
> > > It is not fair to vote for or encourage commits that cost other
> people
> > time.
> > >
> > > -Alex
> > >
> > > On 3/31/20, 12:11 PM
: Piotr Zarzycki<mailto:piotrzarzyck...@gmail.com>
> Sent: Wednesday, April 1, 2020 8:49 AM
> To: Apache Royale Development<mailto:dev@royale.apache.org>
> Subject: Re: [DISCUSS] Coming back to collect requirements for the
> release process
>
> Let'
e CI wouldn’t
> > help.
> >
> > >10) The distribution built by any build system should produce
> > distributions which can be used in any IDE
> >
> > I think your wording suggest that too.
> >
> >
> &
> From: Piotr Zarzycki<mailto:piotrzarzyck...@gmail.com>
> Sent: Wednesday, April 1, 2020 8:49 AM
> To: Apache Royale Development<mailto:dev@royale.apache.org>
> Subject: Re: [DISCUSS] Coming back to collect requirements for the
> release process
>
>
;
Sent: Wednesday, April 1, 2020 8:49 AM
To: Apache Royale Development<mailto:dev@royale.apache.org>
Subject: Re: [DISCUSS] Coming back to collect requirements for the release
process
Let's move forward with whatever you have guys :)
On Wed, Apr 1, 2020, 12:51 A
anges that you wanted to see. Instead, this
> > > effort has cost me considerable time that could have been use
> elsewhere.
> > > It is not fair to vote for or encourage commits that cost other people
> > time.
> > >
> > > -Alex
> > >
> > > On
: Piotr Zarzycki<mailto:piotrzarzyck...@gmail.com>
Sent: Wednesday, April 1, 2020 8:49 AM
To: Apache Royale Development<mailto:dev@royale.apache.org>
Subject: Re: [DISCUSS] Coming back to collect requirements for the release
process
Let's move forward with whatever you have guys :)
O
e thing. The
> scenario
> > as I understood it is about local changes, in which case the CI
wouldn't
> > help.
> >
> > >10) The distribution built by any build system should produce
> > distributions which can be used in any IDE
> >
> >
> > Thanks for that. The Google Doc
> is a
> > > great
> > > > initiative!
> > > > > >
> > > > > > Harbs
> > > >
> > > It is not fair to vote for or encourage commits that cost other people
> > time.
> > >
> > > -Alex
> > >
> > > On 3/31/20, 12:11 PM, "Yishay Weiss" wrote:
> > >
> > > I f
It is not fair to vote for or encourage commits that cost other people
> > time.
> > >
> > > -Alex
> > >
> > > On 3/31/20, 12:11 PM, "Yishay Weiss" wrote:
> > >
> > > I feel like we’re still not talking about the sa
I feel like we’re still not talking about the same thing. The
> scenario
> > as I understood it is about local changes, in which case the CI wouldn’t
> > help.
> >
> > >10) The distribution built by any build system should produce
> > distributions whic
ions which can be used in any IDE
>
> I think your wording suggest that too.
>
>
> From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
> Sent: Tuesday, March 31, 2020 9:32 PM
> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> Subje
<mailto:dev@royale.apache.org>
Subject: Re: [DISCUSS] Coming back to collect requirements for the release
process
Hi,
well yes ... I am assuming that you have CI pipelines for continuously
checking that the builds work.
I wouldn't expect too many RCs to be cancell
at too.
From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
Sent: Tuesday, March 31, 2020 9:32 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: [DISCUSS] Coming back to collect requirements for the release
process
Hi,
well yes ... I am assuming that you
Chris
> > >
> >
> >
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook
gt; >
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cdab1739df18d47111a1208d7d595b752%7Cfa7
t; > > > Will not participate in the other
discussion as
> it’s showing a
> > typical
> > > pattern of progressional-degradation, and
> continuing that thread
> > will not
> >
> it’s showing a
> > typical
> > > pattern of progressional-degradation, and
> continuing that thread
> > will not
> > > bring the project forward.
>
Will not participate in the other discussion as
> it’s showing a
> > typical
> > > pattern of progressional-degradation, and
> continuing that thread
> > will not
> > > bring the project forward.
>
> > Chris
> > >
> >
> >
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C
t;
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b344
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211
> > > Chris
> > >
> >
> >
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7
Forgot to mention:
... as long as all the artifacts are generated:
- Maven artifacts in repos.apache.org
- Source bundle
- Binary Distribution for use in IDEs
Chris
Am 31.03.20, 18:55 schrieb "Christofer Dutz" :
Well you could make the verification part of the verification ...
Let's make it happen :)
wt., 31 mar 2020 o 18:55 Christofer Dutz
napisał(a):
> Well you could make the verification part of the verification ...
>
> As I mentioned ... I am suggesting to create a release with Ant OR Maven
> (not require both) and then make the validation part of the release
>
Well you could make the verification part of the verification ...
As I mentioned ... I am suggesting to create a release with Ant OR Maven (not
require both) and then make the validation part of the release verification
process.
Chris
Am 31.03.20, 18:23 schrieb "Alex Harui" :
Let me
There is a difference between something working and being bit-identical.
But regarding seeing your changes in any IDE. Ideally it wouldn't matter if you
build it with Ant or Maven.
Right now the Maven distribution seems to work in the IDEs it was tested with
... so ... yes.
So if you develop,
Let me try another way: There are.a lot of build.xml files that are intended
to create a tar.gz and .zip (that the Maven distribution will hopefully binary
match someday if not already). How can the RM, in the creation of the release
candidates, verify that the build.xml files will produce
> - Some tooling could be added to validate artifacts created by any form of
> distribution with ones built by Ant
If I understand Alex’s concern correctly he wants Ant users to see their Royale
changes in any IDE. Is this tooling supposed to help with that?
Am 31.03.20, 07:48 schrieb
Hi,
it seems to me like an "extension" or "extra" to the release process, but
not required.
If others want to do, take over but please, don't do it mandatory, since is
not something Apache demands.
When I read what users requested (as we could read in the users thread
about releasing), they
Hi Alex any Yishay
Alex, I think you are again defining a requirement by one of its solutions.
So let me extract the requirements from this (I added it to the list):
10) The distribution built by any build system should produce distributions
which can be used in any IDE
I think the other
Hi Chris,
Last comment from Alex explain exactly what release process has to do
additional. - Did your document explanation included that step? Reading it
I feel it includes, but I would like to make sure.
Thanks,
Piotr
On Tue, Mar 31, 2020, 6:34 AM Alex Harui wrote:
>
>
https://lists.apache.org/thread.html/r6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%40%3Cdev.royale.apache.org%3E
A "build" (running 'ant main') produces jars and swcs but does not create the
same output as 'ant release' which produces tar.gz and .zip files. The release
artifacts
> Ant artifacts are reproducible by running the Ant scripts. Again, the
> scenario is that if an Ant user wants to try a local change in an IDE or NPM
> we want >to ensure that they can run the Ant "release" target and get the
> tar.gz or .zip they need.
“Again” suggests you’ve already given
Hi Alex,
But I do see that Chris took into account that part, unless I don't
understand something.
Thanks,
Piotr
pon., 30 mar 2020 o 17:22 Alex Harui napisał(a):
> This looks like your original offering and does not include my
> recommendations.
>
> I believe the document is missing the
Hi Alex,
I think the best is that you and Yishay take over the process of release
Apache Royale, to avoid the large process of emails that I think is not
carrying us to get the work done.
Thanks
El lun., 30 mar. 2020 a las 17:22, Alex Harui ()
escribió:
> This looks like your original
This looks like your original offering and does not include my recommendations.
I believe the document is missing the requirement that the process of creating
the Ant release artifacts must verify that the Ant artifacts are reproducible
by running the Ant scripts. Again, the scenario is that
Hi Chris,
thanks. I revise and for me is totally fine :)
El lun., 30 mar. 2020 a las 9:33, Harbs () escribió:
> Thanks for that. The Google Doc is a great initiative!
>
> Harbs
>
> > On Mar 30, 2020, at 10:26 AM, Christofer Dutz
> wrote:
> >
> > Hi all,
> >
> > as the discussion has gone back
Thanks for that. The Google Doc is a great initiative!
Harbs
> On Mar 30, 2020, at 10:26 AM, Christofer Dutz
> wrote:
>
> Hi all,
>
> as the discussion has gone back to: “the release should be as in the 13
> steps”, I’d like to re-focus on the probably more important parts:
>
> I already
40 matches
Mail list logo