Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What exactly is a Nightly Build??
- Thread starter macdon401
- Start date
- Sort by reaction score
Yep.
Practically speaking, the nightly build of an open source application (nightlies of closed source apps would be exceedingly rare, and I've never seen one) is the absolute bleeding edge version, with whatever features the developers are currently working on in, but also whatever bugs have cropped up during development still unaddressed.
Using them can be nice in some apps--for example, until the recent alpha releases the nightly versions of Camino had drastically more features than the year-old stable version--but they are often very unstable and in some cases barely work at all when a new feature completely breaks others.
Practically speaking, the nightly build of an open source application (nightlies of closed source apps would be exceedingly rare, and I've never seen one) is the absolute bleeding edge version, with whatever features the developers are currently working on in, but also whatever bugs have cropped up during development still unaddressed.
Using them can be nice in some apps--for example, until the recent alpha releases the nightly versions of Camino had drastically more features than the year-old stable version--but they are often very unstable and in some cases barely work at all when a new feature completely breaks others.
Indeed. Nightly apps are also not at all tested, the developer just works, then compiles. It might not even work at all. It might make you toaster make friends with a sea turtle. 
llama
llama
In the general sense, all code that has been checked-in to a source code control system (like SourceSafe, Clear Case, SCCS, etc.) is automatically scheduled to build every night at some off-peak hour.
In my engineering group a team of developers works on code during the day, compiles and tests the code on their local PCs, and checks-in only the code that is tested to make sure it compiles and links without error. It is not necessary for the code to work properly or to be functionally complete.
After all code check-ins are done at the end of each business day, the automatic nightly build starts at 12am and finishes (for us) at around 5am. Each morning a different engineer is responsible for verifying that the nightly build successfully compiled and linked. If there were any errors, the engineer notifies the approprite fellow team member/s.
When working on a large application with several developers, the nightly build helps us minimize problems with integration builds -- i.e. to make sure that a developer's code changes do not conflict with any other developer's code changes.
As we approach a release target, all pending development work is completed and checked-in, the source code control branch is frozen and labeled, and a formal build is made and tested.
This is a common procedure, but details may vary from organization to organization.
In my engineering group a team of developers works on code during the day, compiles and tests the code on their local PCs, and checks-in only the code that is tested to make sure it compiles and links without error. It is not necessary for the code to work properly or to be functionally complete.
After all code check-ins are done at the end of each business day, the automatic nightly build starts at 12am and finishes (for us) at around 5am. Each morning a different engineer is responsible for verifying that the nightly build successfully compiled and linked. If there were any errors, the engineer notifies the approprite fellow team member/s.
When working on a large application with several developers, the nightly build helps us minimize problems with integration builds -- i.e. to make sure that a developer's code changes do not conflict with any other developer's code changes.
As we approach a release target, all pending development work is completed and checked-in, the source code control branch is frozen and labeled, and a formal build is made and tested.
This is a common procedure, but details may vary from organization to organization.