cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <run...@gmail.com>
Subject Re: release note documentation
Date Thu, 17 Apr 2014 16:03:37 GMT

On Apr 17, 2014, at 5:57 PM, David Nalley <david@gnsa.us> wrote:

> Are you shipping (e.g. making source available for download) tarballs
> or merely producing documentation that we publish publicly.
> If the answer to that is no; then we don't need votes or a formal
> release process (anymore than we need votes for publishing content to
> cloudstack.apache.org

-sources are available through the asf git repo and the github mirror.
-we do not make docs tar ball or packages.
-we do build pdf and potentially epub that people can download

As a matter of fact since the build and publishing platform is external to ASF infra, we (I
since it's my RTD account) are just consuming the docs from git and providing it to the community
like we do with .debs and .rpms .

Good point David, 

> 
> --David
> 
> On Thu, Apr 17, 2014 at 11:43 AM, sebgoa <runseb@gmail.com> wrote:
>> 
>> On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pdion@cloudops.com> wrote:
>> 
>>> Should we have a page on wiki explaining how we would handle release-notes
>>> on RTD ? and then vote on the method?
>>> I'm not seeing other alternative to branches exept having one RTD project
>>> for each release-notes.
>>> 
>> 
>> I think your email here explains it well.
>> 
>> What we need now is a [DISCUSS] thread on whether we want to vote on docs releases
and whether we need a formal release process or not ?
>> 
>> Do you want to start that thread ;)
>> 
>>> 
>>> 
>>> 
>>> 
>>> Pierre-Luc Dion
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> 855-OK-CLOUD (855-652-5683) x1101
>>> - - -
>>> 
>>> *CloudOps*420 rue Guy
>>> Montréal QC  H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>> 
>>> 
>>> On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <david@gnsa.us> wrote:
>>> 
>>>> So I think it makes sense for most documents to point to feature
>>>> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
>>>> materially the same as 4.3.0 from a docs standpoint. Release notes are
>>>> the exception here, though perhaps they could be dealt with in an
>>>> additive way.
>>>> 
>>>> --David
>>>> 
>>>> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <runseb@gmail.com> wrote:
>>>>> To add to what Pierre-Luc said:
>>>>> 
>>>>> Readthedocs has something they call "releases" but those are in fact
>>>> builds that point to a branch. Not a specific tag.
>>>>> 
>>>>> So the release version of the doc we would see on the website will be
>>>> the live state of the release branch, not a tag that we could vote on.
>>>>> 
>>>>> That said, we have not yet discussed whether or not we need to formally
>>>> vote on doc releases :)
>>>>> 
>>>>> -sebastien
>>>>> 
>>>>> 
>>>>> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <daan.hoogland@gmail.com>
>>>> wrote:
>>>>> 
>>>>>> makes sense! the only behavior that needs to be taken into account
is
>>>>>> that of any publication scripts that we might write. So it seems
to me
>>>>>> this is the best result we have from this version of the hackathon
:(
>>>>>> & :)
>>>>>> 
>>>>>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pdion@cloudops.com>
>>>> wrote:
>>>>>>> At the hackathon of CCCNA14 with Sebastien, we made few tests
the RTD
>>>> for
>>>>>>> documentation versioning.
>>>>>>> 
>>>>>>> Look like we can use branch instead of tag for versioning and
we can
>>>> also
>>>>>>> select which branches are published on RTD.org
>>>>>>> 
>>>>>>> So, in order to have doc version match product version, would
it make
>>>> sense
>>>>>>> to create a branch call 4.3.0 for the current CS version and
start
>>>> updating
>>>>>>> master for next version 4.4 ? once we will have 4.4 pretty much
ready
>>>> we
>>>>>>> will be able to create new branch 4.4.
>>>>>>> 
>>>>>>> By using branches it allow us to update documentation without
having to
>>>>>>> update is version.
>>>>>>> 
>>>>>>> Make sense?  Have we missing a potential GIT behaviour  doing
it this
>>>> way?
>>>>>>> 
>>>>>>> 
>>>>>>> Pierre-Luc Dion
>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>> 855-OK-CLOUD (855-652-5683) x1101
>>>>>>> - - -
>>>>>>> 
>>>>>>> *CloudOps*420 rue Guy
>>>>>>> Montréal QC  H3J 1S6
>>>>>>> www.cloudops.com
>>>>>>> @CloudOps_
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Daan
>>>>> 
>>>> 
>> 


Mime
View raw message