How about x.x.x-snapYMD, where x.x.x is the CloudStack version, and YMD is
the date? So you'd have 4.0.0-snap120930, for example?

On Thu, Sep 27, 2012 at 6:08 PM, Wido den Hollander <w...@widodh.nl> wrote:

>
>
> On 09/27/2012 08:08 AM, Rohit Yadav wrote:
>
>> One more proposal;
>>
>> Our CI/Jenkins builds many builds daily, how about it bundles tar balls
>> and at the same time, upload these rpms/debs to a daily rpm/deb repository.
>> This way QA won't have to download these tar balls (they would still can,
>> can install using install.sh), but configure their package managers with
>> the repo URL and do stuff like:
>>
>> apt-get install cloud-server etc.; apt-get upgrade etc.
>>
>> This repo will just hold daily builds and not any releases.
>>
>>
> I've been thinking about that, but we don't increment our package versions
> every day, so apt won't notice any new packages.
>
> We could have indeed have a "daily" section on the repository, but we need
> to think of a way of incrementing the version numbers which apt will pick
> up.
>
> Wido
>
>
>  Regards.
>>
>> On 27-Sep-2012, at 12:54 AM, Wido den Hollander <w...@widodh.nl> wrote:
>>
>>
>>>
>>> On 09/26/2012 08:45 AM, Rohit Yadav wrote:
>>>
>>>>
>>>> On 26-Sep-2012, at 3:22 AM, Wido den Hollander <w...@widodh.nl> wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> I've been working on the Management Server and Hypervisor installation
>>>>> docs lately.
>>>>>
>>>>> About everything was focused on RHEL/CentOS and around "install.sh"
>>>>>
>>>>>
>>>> I agree, a debian user and fan myself, I want us to focus on debian too.
>>>>
>>>>  There is still a lot of work to do, but I'd want to ask the QA team to
>>>>> test the documentation.
>>>>>
>>>>> All my documentation is going into master and I hope this gets cherry
>>>>> picked into the 4.0 branch.
>>>>>
>>>>> Take a look at:
>>>>> http://jenkins.cloudstack.org/**view/master/job/docs-master/**
>>>>> lastSuccessfulBuild/artifact/**Apache_CloudStack-4.0-**
>>>>> cloudstack-en-US.pdf<http://jenkins.cloudstack.org/view/master/job/docs-master/lastSuccessfulBuild/artifact/Apache_CloudStack-4.0-cloudstack-en-US.pdf>
>>>>>
>>>>> Most of my works has gone into Chapter #2: Installation.
>>>>>
>>>>> The big changes:
>>>>> * Document the Debian DEB repository
>>>>> * No longer use "install.sh" but use Apt
>>>>> * Don't let cloud-setup-agent do everything, but document the steps
>>>>> needed to be done (libvirt, firewall, apparmor, selinux)
>>>>> * Make the documentation useable on both RHEL and Ubuntu
>>>>>
>>>>
>>>> Also if we can have a rpm repository too, so we have same kind of
>>>> workflow; yum install <pkg-name> and aptitude install <same-pkg-name>
>>>> Install.sh can stay as well, for both, in case use has downloaded a tar
>>>> ball of debs or rpms.
>>>>
>>>>
>>> I don't know if there will still be a tarball with debs or rpms?
>>> CloudStack itself is only doing a source release, so where should this
>>> tarball come from?
>>>
>>> Wido
>>>
>>>  I'll be working on this the whole week, so it will keep changing these
>>>>> days.
>>>>>
>>>>> Also, Chip is sending out RC3 tomorrow, so I'll update the packages on
>>>>> the Ubuntu repository to RC3 by then as well.
>>>>>
>>>>> Setting up the RPM mirror is something to be done, hopefully this week
>>>>> as well.
>>>>>
>>>>> Any comments or thoughts? Hopefully I'm in the good direction!
>>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>> Wido
>>>>>
>>>>
>>>>
>>


-- 
NS

Reply via email to