The prerelease does more than a normal release build. It not only runs
tests for the package in question, but it also builds the packages which
depend on your package. If you rarely see a difference in a release job and
a prerelease job then you probably are working with a leaf package or one
with very few packages which depend on it.

On Fri, Nov 20, 2015 at 4:40 PM, Asmodehn Shade via ros-release <
ros-release@lists.ros.org> wrote:

> Hi all,
>
> Just my two cents here, but I found prereleases were definitely needed
> when I started to learn how to develop in ROS.
>
> Nowadays however, having setup a private local build farm (one server
> building a few packages), I m starting to think there is no much need to
> test prerelease, or more accurately that releasing on a private local
> buildfarm is a prerelease in itself.
>
> So I m wondering if :
> - that is actually true
> - we could work towards merging these two ( technically and in docs ) and
> have a prerelease process that is roughly :
> "Fork rosdistro, Install that ros-indigo-jenkins-modified on your trusty
> machine, and release your package into the forked rosdistro"
> Which would in fact be the same steps as setting up a local build
> farm/server.
>
> Hopefully this could make things simpler and save time both for developers
> and maintainers, which would make it more stable in the end.
>
> Cheers,
> --
> AlexV
> On Nov 18, 2015 4:07 AM, "Jack O'Quin via ros-release" <
> ros-release@lists.ros.org> wrote:
>
>>
>> On Mon, Nov 16, 2015 at 12:39 PM, Tully Foote via ros-release <
>> ros-release@lists.ros.org> wrote:
>>
>>>
>>> Indeed we agree that getting more prereleases run is important. That's
>>> why we've worked very hard to make sure that it as well as all the jobs are
>>> reproducible.
>>>
>>
>> They are not right now, and that is mostly the fault of docker, which is
>> Not Ready For Prime Time. The fact that everyone has to install the latest
>> docker version coupled with the fact that they release versions with API
>> incompatibilities, makes it an inherently unstable base.
>>
>>
>>> The web hosted solution has elements which are nice for users. However,
>>> it was an expensive pain to maintain. It also provided an inconsistent user
>>> experience, especially if there's a large delay due to waiting for yours or
>>> others jobs to run. As long as it's reproducible it's better to users
>>> leverage their own resources and know reliably when things will run.
>>>
>>
>> I did not mind the delays much, because I could do other tasks while
>> waiting. And, I don't mind using my own resources.
>>
>> I do mind the fact that it frequently does not work, because then I have
>> to spend my own time troubleshooting the situation. Consequently, I choose
>> to focus my testing time on more-productive activities, that seem more
>> likely to find actual bugs in my own code.
>>
>> I understand that OSRF would prefer not to maintain pre-release jobs on
>> the build farm. But, when reasonably-conscientious package maintainers tell
>> you it's not currently a good use of our available testing time to fight
>> with the new pre-release tools, we can anticipate additional problems to
>> ensue.
>> --
>>  joq
>>
>> _______________________________________________
>> ros-release mailing list
>> ros-release@lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-release
>>
>>
> _______________________________________________
> ros-release mailing list
> ros-release@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-release
>
>


-- 
William Woodall
ROS Development Team
william@osrfoundation.org
http://wjwwood.io/