You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by Marco de Abreu <ma...@googlemail.com> on 2018/05/01 22:26:28 UTC

Pre-release versions on website

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

Re: Pre-release versions on website

Posted by Hen <ba...@apache.org>.
Where are said mocks/Krishnan discussions?

On Mon, May 7, 2018 at 5:09 PM Aaron Markham <aa...@gmail.com>
wrote:

> 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 <ba...@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 <si...@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" <ma...@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
> > >     > >
> > >     >
> > >
> > >
> > >
> > >
> >
>

Re: Pre-release versions on website

Posted by Aaron Markham <aa...@gmail.com>.
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 <ba...@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 <si...@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" <ma...@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
> >     > >
> >     >
> >
> >
> >
> >
>

Re: Pre-release versions on website

Posted by Hen <ba...@apache.org>.
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 <si...@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" <ma...@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
>     > >
>     >
>
>
>
>

Re: Pre-release versions on website

Posted by "Afrooze, Sina" <si...@gmail.com>.
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" <ma...@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 <aa...@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
    > >
    >

Re: Pre-release versions on website

Posted by Marco de Abreu <ma...@googlemail.com>.
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 <aa...@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
> >
>

Re: Pre-release versions on website

Posted by Aaron Markham <aa...@gmail.com>.
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
>