edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: What's left to do for Maven migration?
Date Mon, 30 Oct 2017 15:29:40 GMT
Removal of gradle stuff has been committed.
— Dale

> On Oct 30, 2017, at 10:53 AM, Dale LaBossiere <dml.apache@gmail.com> wrote:
> Yes, that helps, thanks.
> I’ve got most of the gradle stuff removed in my workspace and verified everything built,
etc.  I’ll make those other gradle cleanups you mention and commit it.
> Sounds like we can skip the dry-run and just get to “develop” right away (after I
commit the gradle removal).
> Looking forward to the video! It will be very useful.
> — Dale
>> On Oct 30, 2017, at 10:39 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
>> Hi Dale,
>> I guess I could do a „dry-run“-release to check things but I wouldn’t expect
any real problems with this. I could make a short demonstration of that. When doing a real
release, I think it would be a good idea for me to do that and to create a video in which
I explain what has to be done, how and why. 
>> Yes, I agree that splitting the examples into a separate repo is still a good thing
to do. It makes things a lot simpler, I think. But we should merge back first and then ask
Infra to do the split.
>> I would also like to remove all the Gradle stuff as in some of the last commits for
example, you added exceptions to several projects to exclude Gradle stuff. I would like to
remove both the Gradle as well as the Gradle exclusions ;-)
>> Well usually on “master” you have the code state of the last release. “develop”
is where development is done. As soon as a new release is done, master is usually updated
to the new release version. That’s why develop usually produces the “SNAPSHOT” and master
the “RELEASE” versions. 
>> Hope that makes things a little clearer.
>> Chris
>> Am 30.10.17, 15:25 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:
>>> On Oct 29, 2017, at 6:28 AM, Christofer Dutz <christofer.dutz@c-ware.de>
>>> ...
>>> So, it seems the legal stuff has been sorted out, the errors in the output have
been resolved and the problems with periodically failing tests have been resolved. From my
point of view, we could start merging things back to origin/develop … what do you think?
>>   Any need/value in doing some “pre-merge” release process stuff to verify as
much as is possible is in place ready to go after merging? Or will that just unnecessarily
slow things down? See related question about “develop” below.
>>   This week I plan on working on the getting-started and downloads website pages.
 I’ll also work on the RELEASE_NOTES.
>>   A reminder that the samples are to be split off into a separate repo post-merge
- that’s still desired, right?  The main motivation was a separate samples source bundle
as part of our overall release.
>>> Should we remove the Gradle stuff all together? I think right now the project
probably wouldn’t build with the old Gradle as we did change and move around quite some
>>   Yeah, I’m sure it wouldn’t work :-)  Removing all of the gradle pieces in a
single commit would be great.  Is that better left until after the merge? I think I could
go either way.
>>> Would be super awesome if we had this finished in about 2 weeks as then I would
turn on the distribution of SNAPSHOT versions (ok … as soon as the branch name is “develop”
the Jenkinsfile will automatically do that). I would be needing these SNAPSHOTS for the next
sprint of my PLC library project.
>>   That would be great!  FYI, I’m unavailable Nov 8th - 19th.
>>   What’s the relationship between this new “develop” branch and today’s “master”?
 Is the "distribution of develop SNAPSHOTS" just to the ASF nexus snapshots repo?  So can
creating “develop” and merging to it can be done immediately and then work on the actual
release (including updating master) proceed afterwards?
>>   Thanks!
>>   — Dale

View raw message