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> 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