Removal of gradle stuff has been committed.
— Dale
> On Oct 30, 2017, at 10:53 AM, Dale LaBossiere <dml.apa...@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.d...@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.apa...@gmail.com>:
>>
>>
>>> On Oct 29, 2017, at 6:28 AM, Christofer Dutz <christofer.d...@c-ware.de>
>>> wrote:
>>> ...
>>> 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 stuff.
>>
>> 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
>>
>
