Release notes, documentation, oh my!

[Stephen Sadowski]

Hi All,

So 0.8.1 is on pypi, but the docs and release notes still reflect 0.7.0

It's one of my great pet peeves when things like this happen and it is my general opinion that a release should not be cut (in most cases) without at least a plan/timeline in place to update the correlated documentation and release notes.

I'd like to get outside perspective and see if my thinking is sensible or if that's just the way things are and I shouldn't fuss too much about it.

[Adam Hopkins]

I agree. I think this is something that a release procedure should have in  place: a good methodology for the team to document what needs to be added to documentation changes and release notes. If this moves into forward, I think it is important to detail how a PR gets merged and what steps it needs to go thru (including testing and documentation) before it can get added to a release.

I'd be happy to throw out my two cents on a possible structure.... but I'm still waiting to hear back from channelcat and crew as to how they would like to proceed. I don't want to assume anything yet.

--

Adam Hopkins

ad...@amhopkins.com 

Sep 11, 2018, 3:26 PM by stephen....@gmail.com:

--

You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/af3601ea-2f37-41a7-9276-255eb0c6b916%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Sadowski]

In addition to trying to pulling together conduct and contribution guides over the next few days, I'm going to try and put together a changelog and start working on updating documentation.

-S

On Tuesday, September 11, 2018 at 6:35:24 PM UTC-5, Adam Hopkins wrote:

I agree. I think this is something that a release procedure should have in  place: a good methodology for the team to document what needs to be added to documentation changes and release notes. If this moves into forward, I think it is important to detail how a PR gets merged and what steps it needs to go thru (including testing and documentation) before it can get added to a release.

I'd be happy to throw out my two cents on a possible structure.... but I'm still waiting to hear back from channelcat and crew as to how they would like to proceed. I don't want to assume anything yet.

--

Adam Hopkins

ad...@amhopkins.com 

Sep 11, 2018, 3:26 PM by stephen....@gmail.com:

Hi All,

So 0.8.1 is on pypi, but the docs and release notes still reflect 0.7.0

It's one of my great pet peeves when things like this happen and it is my general opinion that a release should not be cut (in most cases) without at least a plan/timeline in place to update the correlated documentation and release notes.

I'd like to get outside perspective and see if my thinking is sensible or if that's just the way things are and I shouldn't fuss too much about it.

--

You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

[Richard Kuesters]

I think it was said in the another thread to have a trigger to build the docs on each change (Andy, right?). May I add to work with two separate branches on git to do that as well? One, master, will reflect the last published version to PyPI and dev (or develop or current or anything related) which reflects the in-progress next release. I think most of you are aware of this concept (either using git-flow or any other concept that skip my mind right now).

Just my two cents to prevent unaware users on trying something still on development but not released (yet).

I think I'll have more time over the weekend to see some of the issues and action plans 😉

Cheers,

Richard @ vltr

On Fri, Sep 14, 2018 at 10:37 AM Stephen Sadowski <stephen....@gmail.com> wrote:

In addition to trying to pulling together conduct and contribution guides over the next few days, I'm going to try and put together a changelog and start working on updating documentation.

-S

On Tuesday, September 11, 2018 at 6:35:24 PM UTC-5, Adam Hopkins wrote:

I agree. I think this is something that a release procedure should have in  place: a good methodology for the team to document what needs to be added to documentation changes and release notes. If this moves into forward, I think it is important to detail how a PR gets merged and what steps it needs to go thru (including testing and documentation) before it can get added to a release.

I'd be happy to throw out my two cents on a possible structure.... but I'm still waiting to hear back from channelcat and crew as to how they would like to proceed. I don't want to assume anything yet.

--

Adam Hopkins

ad...@amhopkins.com 

Sep 11, 2018, 3:26 PM by stephen....@gmail.com:

Hi All,

So 0.8.1 is on pypi, but the docs and release notes still reflect 0.7.0

It's one of my great pet peeves when things like this happen and it is my general opinion that a release should not be cut (in most cases) without at least a plan/timeline in place to update the correlated documentation and release notes.

I'd like to get outside perspective and see if my thinking is sensible or if that's just the way things are and I shouldn't fuss too much about it.

--

You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/af3601ea-2f37-41a7-9276-255eb0c6b916%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/8a26db46-02b9-4fed-af97-3afbdfb19d71%40googlegroups.com.

[Stephen Sadowski]

When I was going through and building the changelog - it seems like there should already be webhooks in place for updating the docs. I think @seemethere is handling that as he works on the documentation.

[Richard Kuesters]

Nice to hear! I'll see what I can do to help during the weekend ;-)

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BPKQO1BCrcvwWuL4xipPwnKdFS-8TWRmVAueZs3-MkUpw%40mail.gmail.com.

[Adam Hopkins]

I generally favor the approach of not merging anything to master until release time. But I also would like to see a structured release schedule with each release having its own dev branch (see my proposal below).

Then, master is the current release on pypi available if we need to make a hot fix. If it is an LTS version, then we also make a branch for that.

--

Adam Hopkins

ad...@amhopkins.com 

Sep 14, 2018, 7:10 PM by rkue...@gmail.com:

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWmMUW8c_eLAVNa_6Uz1Uh_n5zx2kru%2B-Z7oFX6t4XEaUQ%40mail.gmail.com.

[Andy Xu]

Hey, I agree in general, we should try our best to keep master branch stable, anything that needs to merge to master should be fully tested. But master branch doesn't guarantee to be 100% stable until git tag and releasing, we can document this. And pioneers who wanna try latest "stable " code can install from github master branch, they can also provide us feedbacks so that we could address before officially releasing.

For documentation, readthedoc also provides different tags, like stable/latest. We can map that to our corresponding branches.

[Richard Kuesters]

That sounds good to me :-)

On Sat, Sep 15, 2018 at 3:34 PM Andy Xu <yunx...@gmail.com> wrote:

 
Hey, I agree in general, we should try our best to keep master branch stable, anything that needs to merge to master should be fully tested. But master branch doesn't guarantee to be 100% stable until git tag and releasing, we can document this. And pioneers who wanna try latest "stable " code can install from github master branch, they can also provide us feedbacks so that we could address before officially releasing.

For documentation, readthedoc also provides different tags, like stable/latest. We can map that to our corresponding branches.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/d101ae66-8eae-4d4d-ac1f-4abe12261eed%40googlegroups.com.

[Henrik Sommerland]

I concur with Andy. I don't think the master branch and the latest released version should necessarily be the same.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zW%3DAX8p9wMe-Jo28QwUKqcqgwUMkbiimeR%2B44MEXo6xWcA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Henrik "TheGrandmother" Sommerland

[Richard Kuesters]

Yeah, they don't have to. It was just an example based on some practices already known and not necessarily "the plan" :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CAK_c-XJrqFe4qPGbEuSmi%3DXtgkJApNC8TQ5uRS4iOndnZz4_Xg%40mail.gmail.com.