By: mk 
on 22 August 2023 - 09:01
Tags:
Topics:
ชุดโปรแกรมสำนักงาน LibreOffice ออกเวอร์ชัน 7.6 ตามรอบการออกทุก 6 เดือน สิ่งสำคัญคือ LibreOffice 7.6 ถือเป็นเวอร์ชันสุดท้ายที่ใช้ระบบเลขเวอร์ชันแบบดั้งเดิม โดยเวอร์ชันหน้าจะเปลี่ยนมาใช้ระบบเลขแบบใหม่ "ปี.เดือน" คือ LibreOffice 24.2 กำหนดออกเดือนกุมภาพันธ์ 2024
ของใหม่ใน LibreOffice 7.6 ได้แก่
- รองรับ zoom gesture ผ่านทัชแพด
- รองรับธีมสีของเอกสาร สามารถ import/export ธีมได้สำหรับเอกสาร ODF, OOXML
- ปรับปรุงการใช้งานฟอนต์ในภาษาที่เขียนจากขวาไปซ้าย
ของใหม่ของโปรแกรมต่างๆ ในชุด ดูได้จากคลิปท้ายข่าว
ที่มา - LibreOffice
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- สงคราม GenAI บนคลาวด์ในปี 2024 ไปถึงไหนกันแล้ว | Cloudnone x AWS
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
Comments
ทำไมไม่ใช้ semver ง่ายๆ ไม่มีปัญหา ไม่ต้องคิดมากดี
ตัวอย่างผลของการเอาปีมาเป็นเลข version ก็มียังจะใช้อยู่อีก
สำหรับผมเป็นปีเดือน manage ง่ายอยู่ครับ
ถ้าต้องดูหลายโปรเจค คือดูความเก่าใหม่
ไม่งั้นต้องมาทำความเข้าใจเพิ่มว่า version นี้ จะขึ้น major ได้ยัง
เงื่อนไขในการขึ้นคืออะไร หรืออันนี้ควร minor หรือ patch
ที่จริง semver มัน concept ง่ายกว่าที่คิดครับ
อัพ major เมื่อมี break change, ไม่ compactible กับ version ก่อนหน้า
อัพ minor เมื่อมี update/new feature
อัพ patch เมื่อแก้ bug/security
ถ้าใครชอบ update dependency บ่อยๆ semver จะมีประโยชน์มากดูแค่เลข version ก็รู้ควรจะ update หรือไหม
ตัวอย่างที่ใช้ปีเป็นเลข version ก็มี c++ นี่ล่ะครับ
c03 c11 c98
ถ้าใครไม่รู้ว่าใช้ปีนี้จะงงอยู่นาน
ต่อให้ใช้ระบบปฏิทิน จะให้มันทำงานแบบ semver เหมือนเดิมก็ได้ อย่าง Unity ถ้าเวอร์ชันไม่ข้ามปีก็การันตีได้เลยว่าไม่มี breaking change ยิ่งทำให้ดูแลง่ายกว่าเดิมเพราะเลขปีบอกได้เลยว่าต้องแคร์ breaking change หรือไม่ แล้วไปกำหนดนโยบายเรื่อง back-compat เอาเองทีหลังได้ มันลดความยุ่งยากเรื่อง source maintenance ลงได้เยอะ ครบปีปุ๊บ branch ออกเลย แล้วไปโฟกัสกับเวอร์ชันหลักต่อ สามารถตัด feature update ออกไปในเวอร์ชันรองได้ง่ายกว่า เน้นเพิ่มของใหม่ใน upstream branch รัว ๆ ได้ทันที
หลัง ๆ ซอฟต์แวร์ที่มี release cycle แน่นอนจะยิ่งหันมาใช้ระบบปฏิทินกันมากขึ้น และส่วนมากซอฟต์แวร์พวกนี้ breaking change น้อยอยู่แล้วเพราะแทบไม่ได้ถอดอะไรออก หรือมี deprecation schedule ที่ชัดเจน คนมีเวลาเตรียมตัวออกมากกว่าพวก SemVer ที่ชอบโยน breaking change ตู้มเดียวแล้วแทบจะต้องแก้ไขกระบวนงานยกแผง (เช่น Godot)
แบบ release cycle ก็ ok
แต่ผมคิดว่าจะทำแบบนี้ได้ต้องมี effort ระดับหนึ่งครับ
ถ้าเป็น opensource ที่มี maintainer อยู่คนสองคน ให้ release cycle นี้ไม่น่าไหว
ฉะนั้น semver นี้น่าจะเหมาะกับพวก low effort ด้วย
และถ้าจะเอาไปลง package manger นี้ต้อง semver เท่านั้นด้วยครับ
เพราะไม่งั้น package manger มันเลือกที่ match กับ project requirement ให้ไม่ถูก
ผมใช้ vcpkg แล้วต้องต้อง fix version ของ dependency ตลอด
ไม่งั้นก็ไม่รู้ว่ามันจะเอาอะไรมาให้ เพราะคนเขียน library c, c++ ส่วนใหญ่ชอบตั้งเลข version เป็นปีหรือไม่ก็ตามใจฉัน
ดูไปดูมาเหมือนจะพัฒนาช้ากว่า Google Docs แล้วแฮะ
That is the way things are.