Mỗi bản ứng dụng mang hai con số. Một là số phiên bản người dùng thấy trên kho, thường gồm ba con số cách nhau bằng dấu chấm, lần lượt cho thay đổi lớn, tính năng mới và sửa lỗi. Hai là số bản dựng nội bộ, bắt buộc phải tăng sau mỗi lần gửi lên kho. Còn ghi chú cập nhật thì nên viết cho người dùng, nói rõ cái gì mới, cái gì đã đổi chỗ, cái gì đã bị bỏ.
Chào bạn, đây là Nhà Phát Hành. Số phiên bản và ghi chú cập nhật trông như chuyện vặt, nhưng chúng là cách một ứng dụng nói chuyện với người dùng qua thời gian. Tập này mình kể một cách đánh số dễ hiểu, và cách viết ghi chú mà người ta thật sự đọc.
Số phiên bản và số bản dựng khác nhau thế nào?
Số phiên bản là con số hiện ra với người dùng trên kho và trong phần thông tin của ứng dụng. Nó cho người dùng biết họ đang ở bản nào, và giúp đội hỗ trợ hỏi đúng khi có người báo lỗi.
Số bản dựng là con số nội bộ mà kho dùng để phân biệt từng lần gửi. Mỗi lần bạn gửi một bản mới, dù chỉ sửa một dòng, số bản dựng phải lớn hơn lần trước. Nếu không, kho từ chối nhận.
Một số phiên bản có thể đi kèm nhiều số bản dựng, vì bạn gửi nhiều lần trong quá trình thử nghiệm trước khi chốt bản chính thức.
Hãy để việc tăng số bản dựng tự động trong quy trình dựng ứng dụng, để không ai phải nhớ. Quên tăng số là một lỗi nhỏ mà làm mất cả buổi sáng.
Ba con số mang ý nghĩa gì?
Một quy ước phổ biến là: con số đầu tăng khi có thay đổi lớn, như làm lại giao diện hay thay đổi cách dùng cơ bản. Con số giữa tăng khi có tính năng mới mà không phá vỡ cách dùng cũ. Con số cuối tăng khi chỉ sửa lỗi.
Ví dụ từ một chấm bốn chấm hai lên một chấm bốn chấm ba là sửa lỗi. Lên một chấm năm chấm không là có tính năng mới. Lên hai chấm không chấm không là một thay đổi lớn đáng để người dùng chú ý.
Quy ước này không bắt buộc, nhưng khi đội đã chọn, hãy giữ nhất quán. Người dùng và đội hỗ trợ sẽ quen đọc con số đó như một tín hiệu.
Tránh nhảy số tuỳ hứng, như từ một chấm hai lên năm chấm không vì muốn trông có vẻ trưởng thành. Người dùng lâu năm sẽ thấy lạ, và đội mới vào sẽ không hiểu lịch sử.
Đồng bộ phiên bản giữa hai nền tảng
Nếu ứng dụng có mặt trên cả hai kho lớn, hãy cố gắng giữ cùng một số phiên bản cho cùng một bộ tính năng. Người dùng hai bên nói chuyện với nhau, đội hỗ trợ cũng dễ làm việc hơn.
Nhưng thực tế không phải lúc nào cũng khớp. Một bên có thể phải sửa một lỗi riêng, hay bị kho giữ lại lâu hơn. Khi đó, con số cuối có thể lệch nhau, còn hai số đầu nên giữ giống nhau.
Hãy ghi lại bảng đối chiếu: phiên bản nào trên kho nào có những gì, phát hành ngày nào. Bảng này rất hữu ích khi có người báo lỗi mà không nhớ mình dùng bản nào.
Nếu ứng dụng có cả bản trên trình duyệt, cân nhắc đồng bộ cách đánh số với bản đó để cả đội nói cùng một ngôn ngữ.
Viết ghi chú cập nhật người dùng thật sự đọc
Câu sửa lỗi và cải thiện hiệu năng xuất hiện trên rất nhiều ghi chú cập nhật tới mức người dùng bỏ qua mọi ghi chú. Nếu bản cập nhật chỉ sửa lỗi nhỏ, câu đó chấp nhận được. Nhưng nếu có gì mới, hãy nói rõ.
Viết bằng lời của người dùng, không bằng lời của lập trình viên. Thay vì nói tối ưu hoá mô-đun đồng bộ, hãy nói ảnh của bạn giờ tải lên nhanh hơn khi mạng yếu.
Đặt điều quan trọng nhất lên đầu, vì nhiều nơi chỉ hiện vài dòng đầu. Nếu có thay đổi làm người dùng bối rối, như nút quen thuộc đã chuyển chỗ, hãy nói ngay: nút xuất báo cáo giờ nằm ở góc trên bên phải.
Nếu bỏ một tính năng, hãy nói thẳng và nói lý do, kèm cách thay thế nếu có. Người dùng tự phát hiện tính năng biến mất sẽ bực hơn nhiều so với được báo trước.
Nhật ký thay đổi nội bộ và bản nhiều ngôn ngữ
Ghi chú cập nhật trên kho là phiên bản ngắn cho người dùng. Đội nên có thêm một nhật ký thay đổi nội bộ chi tiết hơn: từng thay đổi, ai làm, liên quan tới báo lỗi nào. Khi có vấn đề sau phát hành, nhật ký này giúp tìm ra nguyên nhân nhanh.
Nếu ứng dụng có nhiều ngôn ngữ, ghi chú cập nhật cũng nên được viết cho từng ngôn ngữ. Người dùng Việt đọc ghi chú tiếng Anh sẽ bỏ qua, và có thể bỏ lỡ điều quan trọng.
Với thay đổi lớn, ghi chú trên kho không đủ. Hãy thông báo thêm ngay trong ứng dụng, lần đầu người dùng mở bản mới, bằng một màn hình ngắn giới thiệu những gì đã đổi.
Người dùng không đọc mã nguồn của bạn. Với họ, ghi chú cập nhật là dấu hiệu duy nhất cho thấy có người đang chăm chút ứng dụng này. Ghi chú cập nhật gần nhất của bạn có cho người dùng lý do để vui khi cập nhật không?
Câu hỏi thường gặp
Số phiên bản ứng dụng có bắt buộc theo quy ước ba con số không?
Không bắt buộc, nhưng đây là quy ước phổ biến và dễ hiểu. Điều quan trọng là đội chọn một cách và giữ nhất quán. Số bản dựng nội bộ thì bắt buộc phải tăng sau mỗi lần gửi.
Quên tăng số bản dựng thì sao?
Kho sẽ từ chối nhận bản gửi vì trùng hoặc nhỏ hơn số đã có. Bạn chỉ cần tăng số và dựng lại. Để tránh, hãy cho quy trình dựng tự tăng số.
Ghi chú cập nhật nên dài bao nhiêu?
Ngắn, đặt điều quan trọng nhất lên đầu. Vài dòng là đủ cho bản nhỏ. Với bản lớn, có thể dài hơn nhưng vẫn nên chia ý rõ ràng và kèm thông báo trong ứng dụng.
Có nên ghi sửa lỗi và cải thiện hiệu năng mỗi lần cập nhật?
Chỉ khi đó thật sự là tất cả những gì bản cập nhật làm. Nếu có tính năng mới hay thay đổi người dùng cần biết, hãy nói rõ. Ghi chung chung mãi làm người dùng bỏ qua mọi ghi chú.
Phiên bản hai nền tảng lệch nhau có sao không?
Không sao nếu có lý do, như một bên sửa lỗi riêng. Hãy giữ hai số đầu giống nhau cho cùng bộ tính năng và lưu bảng đối chiếu để đội hỗ trợ tra cứu.
