mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Markham <aaron.s.mark...@gmail.com>
Subject Re: Pre-release versions on website
Date Tue, 08 May 2018 00:09:32 GMT
The release candidate was removed as an option on the site.

With regard to the default version, I posted about the predominance of
users on master, and all of the feedback I received agreed that master
should be the default view of the website.
If a change of heart occurs regarding the default view of the site, I made
the build_version_doc scripts, and Jenkins job that uses them, easily
configurable, so from the Jenkins job, one may simply change the "site
default" parameter on the nightly site build job. Viola, whatever version
you want as default will appear upon the next run. For now, however, I
think we should stick to what the users on the site seem to want, and
that's master.

That being said, the default installation instructions should reflect the
current release: pip install mxnet. They currently reflect how to install
master, using: --pre. I plan to remedy this soon. Anyone coming to the site
and wanting to get started should see something similar to how pytorch does
it. Their instructions are very clean and simple. Complex installation
information can be posted on a detail pages, but basic install info should
be like one line: pip install mxnet or pip install mxnet-{some-variant}.

Krishnan and I are working on a refactor of the install page to make it
easier to maintain and easier for visitors to the site to get started.
Also, the API docs should have the option to be easily switched and
searching should work within the version you have selected. Again, this is
something Krishnan and I are discussing and attempting to fix. I believe
that between these two updates, we'll have resolved the primary UX problems
with the versions selector, as well as allayed the concerns about clarity
around the API docs. You should know what version of content you're reading
at any point in time. I'm happy to hear any suggestions or requests on this
area as we're in the middle of mocking up some solutions.

Cheers,
Aaron


On Mon, May 7, 2018 at 8:03 AM, Hen <bayard@apache.org> wrote:

> Agreed.
>
> RCs are for the project contributors to review. They are not for users as
> they have not passed the release process. The website shouldn’t reflect
> RCs.
>
> Hen
>
> On Sat, May 5, 2018 at 10:42 PM Afrooze, Sina <sina.beh@gmail.com> wrote:
>
> > I have mentioned this before and I still think that the default MXNet
> > webpage must match the default version that is installed when someone
> > issues "pip install mxnet". - Sina
> >
> >
> >
> > On 5/1/18, 6:43 PM, "Marco de Abreu" <marco.g.abreu@googlemail.com>
> > wrote:
> >
> >     Hi Aaron,
> >     I think it'd be a good idea to create pip packages for the release
> >     candidates. Sheng, would it be possible to incorporate this into your
> > build
> >     pipeline? In my opinion, we shouldn't advertise the RCs not too much
> > on our
> >     website, so I'd say we could skip #2. #3 in combination with #1
> sounds
> > like
> >     a good idea.
> >
> >     In the meantime, we could just patch the install page for 1.2.0 and a
> > big
> >     red warning message that states that this a release candidate and
> that
> > the
> >     publish process is ongoing. This way, we can let the 1.2.0 website
> > stay up
> >     and also avoid confusion. WDYT?
> >
> >     -Marco
> >
> >     On Wed, May 2, 2018 at 1:22 AM, Aaron Markham <
> > aaron.s.markham@gmail.com>
> >     wrote:
> >
> >     > Hi Marco,
> >     > Putting 1.2.0 was meant to allow a preview and for testing, but I
> > see how
> >     > this can cause confusion.
> >     >
> >     > Change the names and/or hiding the RC is possible with some
> > refactoring of
> >     > the site build scripts. I'd be happy to take a look at this.
> >     >
> >     > I think another solution could be:
> >     > 1. create pip installs for each release candidate
> >     > 2. offer each release candidate on the install page (with
> > instructions for
> >     > source and pip installs)
> >     > 3. when there's a dropdown for version, in either the install or
> API
> > docs
> >     > area it maps precisely to the release or release candidate
> >     >
> >     > In the meantime, to prevent confusion, I'll remove 1.2.0 from the
> > site.
> >     > Once we cut the release, or solved the points above, whichever is
> > sooner,
> >     > the version(s) can be reintroduced to the site.
> >     >
> >     > Cheers,
> >     > Aaron
> >     >
> >     > On Tue, May 1, 2018 at 3:26 PM, Marco de Abreu <
> >     > marco.g.abreu@googlemail.com
> >     > > wrote:
> >     >
> >     > > Hello,
> >     > >
> >     > > we have been approached by a few users about the release status
> of
> > MXNet
> >     > > 1.2. One thing that seems to be confusing in particular is the
> > fact that
> >     > we
> >     > > already show version 1.2.0 on our website. Would it be possible
> to
> >     > > blacklist (and remove) pre-release versions from website until
> > they have
> >     > > been approved and published?
> >     > >
> >     > > Best regards,
> >     > > Marco
> >     > >
> >     >
> >
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message