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
