Hi (1) It is recommended that you release using old infrastructure. You should add the DISCLAIMER. You should say that it is a maintenance release as the project transitions to the ASF.
(2) If you need any help with the IBM SGA then let the mentors know. If John agrees then this type of discussion should be on private@. Regards, Dave Sent from my iPhone > On Nov 27, 2017, at 10:18 AM, Mike Beckerle <[email protected]> wrote: > > Ok, so I'd like to put the changes on the support branch, also on master > branch, but then not release it. > > > Should we consider pushing the support branch to NCSA servers - as branch > 2.0.1, and then do a release from that infrastructure? This is a very small > set of changes, but a release is much easier for users to deal with than any > other way of us distributing this. I'm disinclined to just provide a whole > hotfix repo for LWAP because then we're asking users to setup their maven > build system two different ways, one for releases, one for non releases. > > > > > > ________________________________ > From: Steve Lawrence <[email protected]> > Sent: Monday, November 27, 2017 7:41:27 AM > To: [email protected]; Mike Beckerle > Subject: Re: Fw: LWAP project needs a fix to v2.0.0 > > There are a couple of potential issues with this: > > 1) The sbt build infrastructure currently depends on branches and tags > named a certain way. The new branch/tag guidelines break that. Pull > request #3 [1] fixes this and adds "Apache" and "incubating" where > appropriate. This needs an additional +1 before it can be pushed, and it > could be cherry-picked to the v2.0.x support branch, allowing us to > create a release. > > 2) We still do not have SGAs from NCSA and IBM (NCSA is very close), and > so we can not relicense the code base. As I understand it, we cannot do > an Apache release until we get the SGA's signed and code relicensed. > This will likely take some time, especially since we have not done an > official Apache release, and there's much more involved in a release > than just tagging the repo as we've done in the past. I would say the > best solution would be to just create a private copy of the repo for the > LWAP project and tag it using old style tag names (e.g. > 2.0.0-lwap-hotfix-1) which can be provided to LWAP, making it clear it > is not an official Apache release. Once we get the SGAs in place, we can > start the process towards a release and get the LWAP project to start > following that. > > [1] https://github.com/apache/incubator-daffodil/pull/3 > [https://avatars2.githubusercontent.com/u/3180601?s=400&v=4]<https://github.com/apache/incubator-daffodil/pull/3> > > Updates for Apache incubation by stevedlawrence · Pull Request #3 · > apache/incubator-daffodil<https://github.com/apache/incubator-daffodil/pull/3> > github.com > Update URLs to point to apache infrastructure Add Apache incubating > DISCLAIMER Remove the use of git to determine version numbers. The version is > now hardcoded in build.sbt and needs to be updated ... > > > > >> On 11/22/2017 01:46 PM, Mike Beckerle wrote: >> Forgot to send to the dev list. >> >> >> ________________________________ >> From: Mike Beckerle >> Sent: Wednesday, November 22, 2017 1:30 PM >> To: Stephen Lawrence; Taylor Wise; Joshua Adams; Dave Thompson >> Subject: LWAP project needs a fix to v2.0.0 >> >> >> So in building some DFDL shcemas for LWAP I found a bug that need to be >> fixed. It basically is blocking progress. >> >> >> I created a pull request for merge onto the support/v2.0.x branch. >> >> >> If this is acceptable, then the issue arises of how we create a point >> release, which we haven't done as yet. >> >> >> Would this release be called 2.0.1 ? being a tag on the support/v2.0.x >> branch? >>
