I'd be glad to see dmlc migrated into the mxnet project and remove it as a
third party dependency. But considering the fact that dmlc is currently not
related to Apache MXNet, we have to expect all third party libraries being
properly tested and maintained by their creators.
-Marco
Am 25.01.2018
Hi everyone,
Just some status update regarding the release:
1. More license fixes by @mbaijal are merged.
https://github.com/apache/incubator-mxnet/pull/9554 for the perl package
https://github.com/apache/incubator-mxnet/pull/9556 for the docs folder
Hi,
I just wanted to bring a bit more attention to this case. We have had at
least 3 runs fail in the last 48 hours and it seems like an actual bug has
been introduced.
-
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/master/284/pipeline
-
I support the proposal from Nan - this is a practical and productive way. I
include Nan's description into
https://cwiki.apache.org/confluence/display/MXNET/Release+Versioning+and+Branching
We should make API changes very carefully and need to depend on the
community to flag any changes until we
@Marco: Ok, well then it sounds like a good time for the community to
re-think how we look for API changes ;-). We can continue the chat in the
semver proposal, but maybe we could create a collection of APIs we consider
to be semver'd and review those interfaces each release. Spending reviewer
Yes this is also what I'd suggest Nan, sorry if I wasn't clear. My comment
was referring to 2. So as an example for our current release we could cut
a new minor release including new features such as the text api, scala
rename, but we could cherry-pick the important bug fixes and apply them to
regarding "I'd agree that we should apply most of the fixes to the previous
release branch and build from there."
my suggestion is actually a bit different with this, my idea is that
1. we always work with master branch, and when there is a date for
releasing a new version (minor or major) one,
By my count we have four mechanisms in place to verify no breaking API
changes have taken place:
1) Have the important public api's changed? This can be verified in by
inspecting git history of important interfaces.
2) Has anyone indicated in a PR that their change was a breaking change
Hi Kellen,
The reason I proposed a minor release is the matter of the fact that we do
not know if we have no breaking changes. We currently have no mechanism in
place to validate this fact and while you are right that this will probably
result in a slower adoption rate, I'm more afraid about
+1 (non-binding) to points 1-5.
For point 3 I would suggest we come up with a heuristic for support
status. For example we announce each release that we are dropping support
for all prior releases that A) have less than 5% pip usage and B) are 3
minor releases old or older.
On Tue, Jan 23, 2018
-.5 (non-binding) to releasing as a minor release. If we don't have any
breaking API changes, and we haven't added any major features I would tend
to release this as a patch release. The reason being that organizations
and users will know that they can apply this release without making major
11 matches
Mail list logo
