Quản lý phát hành trong các dự án phần mềm nguồn mở

Release management in open source software projects

By Sander van der Waal, Published: 26 October 2010, Reviewed: 12 November 2012

Theo: http://www.oss-watch.ac.uk/resources/releasemanagement

Bài được đưa lên Internet ngày: 12/11/2012

Lời người dịch: Nguyên tắc của phát triển phần mềm tự do nguồn mở (PMTDNM) là phát hành sớm và phát hành thường xuyên. Để điều này xảy ra được, cần tới một qui trình phát hành được xác định trước một cách hợp lý và rõ ràng. “Là cơ bản để có một qui trình được xác định tốt hiện diện cho việc tạo ra các phát hành đó - quan trọng hơn nhiều, trong thực tế, hơn hầu hết các hoạt động khác trong phát triển phần mềm. Điều này là cần thiết để đảm bảo rằng tất cả các vấn đề pháp lý được giải quyết và rằng chất lượng của một phát hành là đủ tốt để là hữu dụng cho những người sử dụng. Điều này không có nghĩa là một phát hành phải là hoàn chỉnh hoặc rằng nó phải là không có lỗi; trong thực tế, điều này không bao giờ thực sự là như vậy cả. Nó đơn giản có nghĩa là tình trạng của từng phát hành là được làm thành tài liệu tốt, để quản lý những kỳ vọng của người sử dụng”. Bài viết chỉ ra cho bạn tỉ mỉ từng giai đoạn trong qui trình phát hành rất quan trọng này.

Quản lý phát hành là về quản lý qui trình xây dựng, đóng gói và phân phối phần mềm để tiêu dùng. Trong tài liệu này chúng tôi sẽ giải thích qui trình quản lý phát hành trong các dự án phần mềm nguồn mở (PMNM) và nhấn mạnh tới các bước quan trọng nhất trong qui trình đó. Chúng tôi cũng đã xuất bản một tài liệu nói thêm về các chi tiết kỹ thuật của thực tiễn tốt nhất trong quản lý phát hành và đưa ra một danh sách chọn có thể là hữu dụng khi làm một phát hành.

Giới thiệu

Trong các dự án PMNM, điều quan trọng là phần mềm được phát hành sớm và thường xuyên. Là cơ bản để có một qui trình được xác định tốt hiện diện cho việc tạo ra các phát hành đó - quan trọng hơn nhiều, trong thực tế, hơn hầu hết các hoạt động khác trong phát triển phần mềm. Điều này là cần thiết để đảm bảo rằng tất cả các vấn đề pháp lý được giải quyết và rằng chất lượng của một phát hành là đủ tốt để là hữu dụng cho những người sử dụng. Điều này không có nghĩa là một phát hành phải là hoàn chỉnh hoặc rằng nó phải là không có lỗi; trong thực tế, điều này không bao giờ thực sự là như vậy cả. Nó đơn giản có nghĩa là tình trạng của từng phát hành là được làm thành tài liệu tốt, để quản lý những kỳ vọng của người sử dụng.

Bạn sẽ thấy rằng các công cụ là quan trọng trong một dự án PMNM cũng đóng một vai trò không thể thiếu trong quản lý phát hành. Các công cụ quan trọng nhất trong khía cạnh này là:

• Các danh sách thư cho giao tiếp

• Trình theo dõi các vấn đề (issue tracker) cho việc lên kế hoạch các phát hành và quản lý phạm vi

• Hệ thống kiểm soát phiên bản cho việc theo dõi và giám sát mã được phát hành

Có một số vai trò trong qui trình quản lý phát hành. Trong giai đoạn sớm của dự án, có khả năng là những vai trò đó sẽ được một người duy nhất triển khai. Khi dự án chín muồi, chúng có thể được chia tách và đại diện cho các thành viên các đội khác nhau. Các vai trò khác nhau trong các qui trình quản lý phát hành là:

• Kiến trúc sư (Architect): người có trách nhiệm cho việc nhận diện, tạo và triển khai qui trình phát hành

• Người quản lý (Manager): người giám sát qui trình phát hành

• Người tạo thuận lợi (Facilitator): liên lạc giữa tất cả các biên đóng góp trong một phát hành

Hãy nhìn qua hầu hết các bước quan trọng trong qui tình quản lý phát hành.

Phạm vi và kế hoạch

Có một số vấn đề thường là quan trọng cho các dự án nguồn mở, nhưng trở nên sống còn khi dự án xem xét tạo ra một phát hành. Trước hết, là cơ bản để đảm bảo sự tương thích giấy phép của mã. Có khả năng là mã của dự án phụ thuộc vào một số thư viện bên ngoài, mỗi thư viện của nó sẽ có giấy phép phần mềm của riêng nó. Kiến trúc sư sẽ phải kiểm tra liệu giấy phép của thư viện đó có cho phép dự án phân phối lại nó với mã của riêng nó hay không. Lý tưởng là, điều này sẽ xảy ra lần đầu thư viện này được sử dụng trong dự án, nhưng trong bất kỳ trường hợp này phải chắc chắn rằng mọi vấn đề về sở hữu trí tuệ (IP) được quan tâm. Hệt như với tính tương thích về giấy phép, điều này nên được thực hiện trên cơ sở liên tục, những đặc biệt quan trọng khi chuẩn bị phát hành mã.

Khi chuẩn bị một phát hành mới, người quản lý phát hành cần xác định phạm vi và kế hoạch của nó. Họ nên kéo vào những người đệ trình (committer) và những người sử dụng và tìm kiếm một vài mức thỏa thuận từ họ vè phạm vi và kế hoạch của phát hành. Điều này là vì người sử dụng sẽ đóng một vai trò rất quan trọng trong việc kiểm thử phát hành trong tương lai và áp dụng phát hành một khi nó được làm xong. Vì lý do này, tất cả giao tiếp về phạm vi và kế hoạch của phát hành sẽ là truy cập được công khai, ví dụ thông qua một danh sách thư công cộng. Trong khi qui trình này thường được người quản lý phát hành giám sát, thì nó có thể được người tạo thuận lợi kiểm soát.

Trọng tâm đối với qui trình lên kế hoạch phát hành là trình theo dõi các vấn đề. Công cụ này được sử dụng để làm tài liệu cho tình trạng của tất cả các vấn đề có liên quan tới dự án và cung cấp một phương tiện lập lịch và theo dõi các vấn đề nào sẽ có trong phát hành nào. Phạm vi và kế hoạch của phát hành đạt được như thế nào sẽ phụ thuộc phần lớn vào cách mà dự án được điều hành. Từ quan điểm kỹ thuật, nó thường sẽ là kiến trúc sư, người sẽ cần phải phân tích danh sách các vấn đề còn chưa được giải quyết trước khi phát hành. Trong sự cộng tác với người quản lý phát hành, họ sẽ quyết định những vấn đề nào sẽ được giải quyết trong phát hành này và những vấn đề nào sẽ được chuyển sang một phát hành sau đó. Họ sẽ không cố gắng sửa tất cả các vấn đề trong bất kỳ phát hành nào được đưa ra khi điều này là một cách chắc chắn để đảm bảo rằng phát hành đó sẽ không bao giờ xảy ra. Bất kỳ vấn đề nào bị chậm sẽ được chuyển sang một phát hành muộn sau trong trình theo dõi các vấn đề sao cho một danh sách các vấn đề được biết và lộ trình cho phát hành đó có thể được tạo ra. Nếu vấn đề đó trước đó đã được lên lịch cho một phát hành nhưng sau khi cân nhắc bị trễ lại, thì điều này nên được ghi lại trong tài liệu phát hành sao cho người sử dụng sẽ biết rằng phần này của lịch còn chưa được đáp ứng.

Sự không giữ đúng thời hạn của một vấn đề không phải lúc nào cũng là điều không tốt, vì thế thường không phải là một vấn đề nếu các vấn đề được chuyển sang một phát hành khác. Nó sẽ phục vụ như một sự nhắc nhở cho những người sử dụng dự án về những gì họ có thể mong đợi trong phát hành tiếp sau. Nếu người quản lý phát hành chỉ rõ ràng rằng các lập trình viên tích cực sẽ không giải quyết được một vấn đề được đưa ra trong một phát hành được đưa ra, thì người sử dụng có thể quyết định nó là quan trọng tới đâu đối với họ. Nếu điều đó đủ quan trọng, thì bản thân họ sẽ có thể đóng góp cho dự án bằng việc cung cấp một bản vá. Điều này chỉ là một ví dụ về vì sao giao tiếp là cơ bản cho việc giữ cho từng người có được thông tin thông qua qui trình đó.

Đánh số phiên bản

Mỗi phát hành sẽ được nhận diện một cách duy nhất bằng một số phiên bản. Các số đó không hoàn toàn là tùy ý nhưng được sử dụng tuân theo một sơ đồ đặc biệt mà sẽ cho bạn thông tin bổ sung về phát hành đó. Có những sơ đồ khác nhau cho việc thể hiện các số phiên bản trong các phát hành phần mềm. Chúng tôi sẽ thảo luận ngắn gọn một trong những sơ đồ phổ biến hơn, nơi mà các số phiên bản là ở dạng x.y.z hoặc <chính>.<phụ>.<vi mô> (<major>.<minor>.<micro>.).Số phiên bản chính chỉ tăng khi một lượng các chức năng mới đáng kể được bổ sung vào phát hành trước đó. Trong các trường hợp như vậy, số phiên bản phát hành mới sẽ là (x+1).0.0. Số phiên bản phụ tăng chỉ khi một số chức năng được bổ sung vào phát hành mới, trong trường hợ đó số phiên bản phát hành mới sẽ là x. (y+1).0. Khi phát hành mới chủ yếu là các sửa lỗi, sẽ có cái gọi là phát hành điểm. Số phiên bản của phát hành mới trong các trường hợp như vậy sẽ chỉ có số phiên bản vi mô gia tăng, thành x.y.(z+1).

Tuy nhiên, một số dự án sử dụng các hậu tố trong số phiên bản để chỉ sự ổn định của mã. Ví dụ, -alpha chỉ mã không ổn định, trong khi -beta chỉ mã với giao diện lập trình ứng dụng (API) ổn định nhưng có thể vẫn còn các lỗi trong đó. Các dự án khác sử dụng số phiên bản phụ để chỉ mã ổn định/không ổn định, với một số chẵn cho các phát hành ổn định và một số lẻ cho các phát hành không ổn định. Theo ngữ cảnh này, không ổn định không có nghĩa là không sử dụng được. Nó đơn giản có nghĩa rằng mã có thể thay đổi trong phát hành tiếp sau. Nó phục vụ như một cảnh báo cho những người sử dụng tiềm năng rằng họ chỉ neenn sử dụng các phát hành đó nếu họ được chuẩn bị để đặt nỗ lực vào trong việc duy trì phần mềm của họ khi nâng cấp. Điều này có thể đòi hỏi một số bước thêm bằng tay trong nâng cấp.

Các ứng viên phát hành

Là thực tiễn tốt để tạo một ứng viên phát hành RC (Release Candidate) trước khi xuất bản một phát hành cuối cùng. Một RC là một phát hành thông thường, ngoại trừ là số phiên bản có một hậu tố -Rcx (x bắt đầu ở 1 và gia tăng với từng RC mới) để chỉ rằng đây chưa là phát hành cuối cùng. Điều này có nghĩa là nó còn chưa được phê chuẩn và có thể chứa các lỗi sống còn. Lý do cho việc tạo một RC là để đưa vào một chu kỳ kiểm thử trong qui trình phát hành. Mỗi phát hành nên được kiểm thử trên càng nhiều nền tảng và từ càng nhiều người sử dụng càng tốt, và cách tốt nhất để làm thế là bằng việc phân phối một RC. Một RC khác với một phát hành cuối cùng chỉ ở hậu tố số phiên bản; ngoài điều đó ra, đây là một phát hành thông thường.

RC sẽ được tạo ra bằng việc sử dụng hệ thống kiểm soát phiên bản. Quản lý phát hành là một trong nhiều lý do quan trọng vì sao sử dụng một hệ thống kiểm soát phiên bản là sống còn cho một dự án phần mềm. Nó cho phép dự án phát triển tiếp trong nhánh chính hoặc thân của dự án, trong khi công việc tiếp tục về phát hành trong một nhánh phát hành riêng rẽ mà không xung đột với các hoạt động phát triển chính. Thậm chí khi đội dự án không muốn tạo một nhánh phát hành, họ sẽ vẫn tạo một thẻ sao cho họ có thể luôn quay ngược lại và tạo lại phát hành từ mã nguồn y hệt.

Là hữu dụng để áp dụng một qui ước đặt tên hợp lý khi tạo một nhánh phát hành hoặc một thẻ. Điều này cho phép các thẻ phát hành sẽ được được ra dễ dàng. Thông thường, thẻ đó sẽ là một biến thể về tên của phát hành. Ví dụ, một số dự án sử dụng ALL CAPS để chỉ các thẻ phát hành. Vì thế, foo-1.2 có thể được đặt thẻ FOO-1-2. Thường là tốt hơn để sử dụng '-' hơn là '_' như trong hầu hết các trình duyệt thì '_' bị mất khi một siêu liên kết được gạch chân.

Giao tiếp với cộng đồng là rất quan trọng ở từng giai đoạn của qui trình phát hành, nhưng đặc biệt như vậy trong giai đoạn ngay trước khi kiến trúc sư tạo ra nhánh phát hành. Vì bản chất tự nhiên được phân tán của các dự án nguồn mở, sự giao tiếp là cơ bản để chắc chắn rằng tất cả các lập trình viên sẽ đề xuất mã mà là một phần của phạm vi của dự án được đồng ý, đúng lúc. Sau khi tất cả mã đã được đệ trình, kiến trúc sư có trách niệm tạo ra nhánh phát hành. Là thực tiễn tốt để triển khai một sự làm đông lạnh mã khi kiến trúc sư đang làm việc về điều này. Chính trách nhiệm của người tạo thuận lợi để thông tin cho cộng đồng rằng nhành phát hành đã được tạo ra.

Sau khi nhánh đã được tạo ra, kiến trúc sư sẽ lắp ráp các tệp nhị phân. Điều này sẽ được tự động càng nhiều càng tốt để tránh nhân bản nỗ lực và làm dễ cho qui trình tạo một phát hành. Thông thường, vài gói phân phối sẽ được lắp ráp ở giai đoạn này cho các nền tảng khác nhau mà dự án hỗ trợ. Vì chúng ta đang nói về các dự án nguồn mở, nên dự án cũng sẽ cung cấp các tệp nguồn trong một phân phối nhị phân, bao gồm những chỉ dẫn rõ ràng về cách để xây dựng ứng dụng. Điều này khuyến khích mọi người đóng góp bằng việc giảm thiểu số lượng các vòng họ cần phải nhảy qua để có được nguồn. Các phân phối sẽ được làm cho sẵn sàng như là các tệp được nén, thường là các tệp zip cho Windows, tar.gz cho Linux và Apple Disk Image (tệp .dmg) cho những người sử dụng Mac. Ở giai đoạn này, tài liệu cũng phải được kiểm tra và được mở rộng ở những nơi cần thiết.

Xuất bản và kiểm thử RC

Pha tiếp theo của qui trình phát hành là để làm RC sẵn sàng để kiểm thử. Các gói có thể được phân phối thông qua website, nhưng nó phải rõ ràng đối với những người sử dụng rằng nó còn chưa phải là phát hành cuối cùng. Nếu dự án đang phát triển một ứng dụng web, có thể có một máy chủ demo sẵn sàng. Nếu RC là sẵn sàng trên máy chủ demo, thì sẽ là dễ dàng hơn cho những người sử dụng ít biết kỹ thuật hơn để giúp kiểm thử RC. Sự sẵn sàng của RC nên được công bố rộng rãi trong các kênh công khai để chắc chắn rằng nó được càng nhiều người kiểm thử càng tốt trên càng nhiều nền tảng càng tốt.

Hướng tới phát hành cuối cùng

Các lỗi được thấy trong RC sẽ phải được sửa trước khi phát hành cuối cùng được tạo ra. Điều này sẽ liên quan tới việc áp dụng một bản vá cho nhánh phát hành và tạo ra một RC với một số phiên bản khác, như với hậu tố -RC2. Qui trình này nên được lặp đi lặp lại cho tói khi không còn lỗi nào nữa được thấy.

Một khi một RC được kiểm thử hoàn toàn, nó cần sự phê chuẩn để tạo thành cơ sở của phát hành cuối cùng. Qui trình phê chuẩn này sẽ phụ thuộc vào mô hình điều hành được dự án áp dụng. Một khi một RC đã được phê chuẩn, người kiến trúc sư sẽ phải tạo ra phát hành cuối cùng. Đây là thực tiễn tốt để ký mật mã cho phát hành cuối cùng sao cho tính toàn vẹn của nó có thể được bất kỳ ai tải nó về kiểm tra được.

Cũng là một ý tưởng tốt để cung cấp một trình cài đặt cho những người sử dụng hiện hành và trong tương lai. Điều này sẽ cho phép họ có được nhanh và dễ dàng và vì thế làm gia tăng những cơ hội mà họ sẽ trao ý kiến phản hồi cho dự án. Các nền tảng khác nhau có các gói cài đặt khác nhau. Có một số trình cài đặt liên nền tảng có thể được sử dụng, dù chúng đặt ra một số hạn chế hiện nay. Tuy nhiên, dự án cũng nên làm cho càng dễ càng tốt cho các bên thứ 3 để cung cấp một trình cài đặt đặc thù nền tảng. Thường điều này có nghĩa không gì hơn việc cung cấp một phân phối nguồn tốt cho họ để làm việc.

Phát hành sau đó phải được làm cho sẵn sàng thông qua các kênh phân phối của dự án. Các kênh đó nên có khả năng điều khiển yêu cầu được mong đợi cho phát hành đó. Tuy nhiên, làm cho một phát hành sẵn sàng là không đủ. Những người sử dụng (trong tương lai) cũng phải nhận thức được về phát hành mới thông qua các công bố tin tức. Người tạo thuận lợi có trách nhiệm về điều này.

Các phát hành là một khoản tin tức chính cho một dự án và nên đặc trưng trong các blog, RSS feed và danh sách công bố của dự án. Người kiến trúc sư sẽ phải cập nhật các hồ sơ của dự án trong các catalog, các kho ứng dụng và các danh sách tương tự. Họ cũng sẽ cần cập nhật tệp DOAP, và chắc chắn tất cả các catalog có DOAP sẽ được phát ra.

Kết luận

Việc phân phối các phát hành là một khía cạnh quan trọng của bất kỳ dự án nguồn mở nào. Nó cho phép mọi người thử dự án dễ dàng hơn và vì thế làm gia tăng cơ hội có được những người đóng góp mới. Vì thế chúng tôi khuyến cáo mạnh mẽ thực thế của việc phát hành sớm. Dù qui trình có thể xem là phức tạp, một khi được thực hiện và được kiểm thử một hoặc hai lần thì nó sẽ trở nên dễ dàng hơn. Cũng là dễ dàng hơn để làm một phát hành trước khi kho mã trở nên lớn hơn, nó là lý do khác vì sao có ý nghĩa để phát hành sớm. Để giúp nhiều hơn một chút về kỹ thuật của qui trình phát hành, chúng tôi có tài liệu khác mô tả một số chỉ dẫn thực tiễn tốt nhất cùng với một danh sách chọn.

Release management is about managing the process of building, packaging and distributing software for consumption. In this document we will explain the process of release management in open source software projects and highlight the most important steps in this process. We have also published a document that elaborates on the technical details of best practice in release management and provides a checklist that can be useful when making a release.

Introduction

In open source software projects, it is important that the software is released early and often. It is essential to have a well-defined process in place for creating these releases - much more important, in fact, than it is for most other activities in software development. This is necessary to ensure that all legal issues are addressed and that the quality of a release is good enough to be useful to users. This does not mean that a release must be complete or that it must be bug-free; in practice, this is never really the case. It simply means that the status of each release is well documented, in order to manage user expectations.

You will see that the tools that are important in an open source software project also play an indispensable role in release management. The most important tools in this respect are:

• Mailing lists for communication

• The issue tracker for release-planning and scope management

• The version control system for tracking and tracing the released code

There are a number of roles in the release management process. In an early-stage project, it is likely that these roles will be carried out by a single person. As a project matures, they can be separated out and delegated to different team members. The different roles in the release management process are:

• Architect: the person responsible for identifying, creating and implementing the release process

• Manager: the person overseeing the release process

• Facilitator: the liaison between all stakeholders in a release

Let’s take a look at the most important steps in the release management process.

Scope and planning

There are a couple of issues that are generally important for open source projects, but become crucial when the project considers creating a release. First of all, it is essential to ensure licence compatibility of the code. It is likely that the project’s code depends on some external libraries, each of which will have its own software licence. The architect will have to check whether the licence of that library permits the project to redistribute it with its own code. Ideally, this will happen the first moment this library is used in the project, but in any case should be no later than when the first release is prepared. Also, it is important for the project to make sure that all issues regarding intellectual property (IP) have been taken care of. Just as with licence compatibility, this should be done on an ongoing basis, but is especially important when preparing a release of the code.

When preparing a new release, the release manager needs to determine its scope and planning. They should involve the committers and users and seek some level of agreement f-rom them about the scope and planning of the release. This is because the users will play a very important role in testing the prospective release and adopting the release once it has been made final. For this reason, all communication about the scope and planning of the release should be publicly accessible, for example via a public mailing list. While this process is usually overseen by the release manager, it may be controlled by the facilitator.

Central to the release-planning process is the issue tracker. This tool is used to document the status of all issues relating to the project and provides a means of scheduling and keeping track of which issues will be in which release. How the scope and planning of the release is achieved depends largely on how the project is governed. F-rom a technical perspective, it will usually be the architect who will need to analyse the list of unresolved issues prior to release. In collaboration with the release manager, they will decide which issues will be resolved in this release and which will be moved to a later release. They should not attempt to fix all issues in any given release as this is a sure way of ensuring that the release never happens. Any issues that are to be delayed should be moved to a later release in the issue tracker so that a known issues list and a roadmap for the release can be cre-ated. If the issue had previously been scheduled for a release but after consideration is being delayed, this should be recorded in the release documentation so that users will know that this part of the schedule has not been met.

Slippage of an individual issue is not always a bad thing, so it is generally not a problem if issues are moved to a later release. It will serve as a reminder to the project’s users about what they can expect in the next release. If the release manager clearly indicates that the active developers will not address a given issue in a given release, users can decide just how important it is to them. If it is important enough, they can contribute to the project themselves by providing a patch. This is just one example of why communication is essential for keeping everybody informed throughout the process.

Version numbering

Each release will have to be uniquely identifiable by a version number. These numbers are not fully arbitrarily but are used according to a specific scheme that will give you additional information about the release. There are various schemes for expressing version numbers in software releases. We will briefly discuss one of the more common schemes, whe-reby version numbers are of the form x.y.z or <major>.<minor>.<micro>. The major version number is increased only when a significant amount of new functionality is added to the previous release. In such cases, the new release version number will be (x+1).0.0. The minor version number is increased only when some functionality is added to the new release, in which case the new release version number will be x.(y+1).0. When the new release consists mainly of bug fixes, there will be a so-called point release. The version number of the new release in such cases will only have the the micro version number increased, resulting in x.y.(z+1).

Some projects, however, use postfixes in the version number to indicate the stability of the code. For example, -alpha indicates unstable code, while -beta indicates code with a stable API (Application Programming Interface) but that may still have bugs in it. Other projects use the minor version number to indicate stable/unstable code, with an even number for stable releases and an odd number for unstable releases. In this context, unstable does not mean it is unusable. It simply means that the code may change in the next release. It serves as a warning to potential users that they should only use these releases if they are prepared to put the effort into maintaining their software when it comes to upgrading. This may require some extra manual steps in the upgrade.

Release candidates

It is good practice to cre-ate a release candidate (RC) before publishing a final release. An RC is a normal release, except that the version number has a postfix -RCx (x starting at 1 and increasing with every new release candidate) to indicate that it is not the final release. This means that it has not yet been approved and may contain critical bugs. The reason for creating an RC is to include a test cycle in the release process. Every release should be tested on as many platforms and by as many users as possible, and the best way to do that is by distributing an RC. An RC differs f-rom a final release in the version number postfix only; other than that, it is a regular release.

The release candidate will be cre-ated using the version control system. Release management is one of the many important reasons why using a version control system is so crucial to a software project. It allows the project to develop further on the main branch, or trunk, of the project, while work continues on the release in a separate release branch without interfering with the main development activities. Even when the project team doesn’t want to cre-ate a release branch, they should still generate a tag so they can always go back and recre-ate the release f-rom the same source code.

It is useful to adopt a reasonable naming convention when creating a release branch or a tag. This allows release tags to be recognised easily. Typically, the tag will be a variation on the name of the release. For example, some projects use ALL CAPS to indicate release tags. Thus, foo-1.2 would be tagged FOO-1-2. It is generally better to use ‘-‘ rather than ‘_’ as in most browsers the ‘_’ gets lost when a hyperlink is underlined.

Communication with the community is very important at every stage of the release process, but especially so in the period just before the architect cre-ates the release branch. Because of the distributed nature of open source projects, communication is essential for making sure that all developers will have committed the code that is part of the agreed scope of the project, in time. After all code has been committed, the architect is responsible for generating the release branch. It is good practice to implement a code freeze when the architect is working on this. It is the facilitator’s responsibility to inform the community that the release branch has been cre-ated.

After the branch has been cre-ated, the architect will assemble the binaries. This should be automated as much as possible to avoid duplication of effort and to ease the process of creating a release. Usually, several distribution packages will be assembled at this stage for the different platforms the project supports. Since we are talking about open source projects, the project should also provide the source files within a binary distribution, including clear instructions on how to build the application. This encourages people to contribute by minimising the number of hoops they need to jump through in order to get to the source. Distributions should be made available as compressed files, typically zip files for Windows, tar.gz for Linux and an Apple Disk Image (.dmg file) for Mac users. At this stage, the documentation must also be checked and expanded whe-re needed.

Publish and test the release candidate

The next phase of the release process is to make the release candidate available for testing. The packages can be distributed through the website, but it must be clear to users that it is not yet a final release. If the project is developing a web application, there may be a demo server available. If the release candidate is available on the demo server, it will be easier for less technical users to help test the release candidate. The availability of the release candidate should be announced widely on the publication channels to make sure that it gets tested by as many people and on as many different platforms as possible.

Towards the final release

Critical bugs or errors found in the release candidate will have to be fixed before the final release is cre-ated. This will involve applying a patch to the release branch and creating a new release candidate with a different version number, i.e. with the postfix -RC2. This process should be repeated until no more critical errors are found.

Once a release candidate has been fully tested, it needs approval to form the basis of the final release. This approval process will depend on the governance model adopted by the project. Once a release candidate has been approved, the architect will have to cre-ate the final release. It is good practice to cryptographically sign the final release so that its integrity can be checked by anyone who downloads it.

It is also a good idea to provide an installer for current and prospective users. This will allow them to get going quickly and easily and thus increase the chances that they will give the project feedback. Different platforms have different install packages. There are some cross-platform installers, which can be used, although they impose some limitations at present. However, the project should also make it as easy as possible for third parties to provide a platform-specific installer. Often this means nothing more than providing a good source distribution for them to work with.

The release must then be made available via the project’s distribution channels. These channels should be capable of handling the expected demand for the release. However, making a release available is not enough. The (prospective) users must also be made aware of the new release via news announcements. The facilitator is responsible for this.

Releases are a major news item for a project and should feature in the project’s blogs, RSS feeds and announcement list. The architect will have to up-date the project’s records in catalogues, app stores and similar lists. They will also need to up-date the DOAP file, and make sure all DOAP-powered catalogues are pinged.

Conclusion

Distributing releases is an important aspect of any open source project. It enables people to try out the project more easily and hence increases the chance of getting new contributors. Therefore we highly recommend the practice of releasing early. Although the process may seem complicated, once it is in place and it has been tried once or twice it will become easier. It is also easier to make a release before the codebase gets large, which is another reason why it makes sense to release early.

To help with the more technical bits of the release process, we have another document that describes some best practice guidelines along with a checklist.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com