Is there a way to advertise and have consumers tell from the available REST APIs for repos or their branches or releases that particular releases or major version branches are actively supported, maintenance support, or unsupported? Or application of some common support policy, like "n-2 major releases supported"?
This is towards writing automation that can alert, or even automate updating of dependent versions based on availability (e.g., there's a supported version to upgrade from my maintenance version).
From the GitHub API alone, no, as the notion of "support" is not a primary notion.
You could setup for a release naming convention, which would then allow the interpretation of the repos/releases API.
Or describe that support explicitly in the README that you can get through the repos/contents API.
But any solution you might consider will involve some kind of convention/normalization.
Related
Why do some GitHub repos have 0.x.y releases if version 1.0.0 is the first public API release per SemVer2? Isn't 0.x.y development before the first complete working code you want to release to the public (i.e. wouldn't anything pre-1.0 not be usable)? I am specifically referring to repos that want to claim they are following semantic versioning.
THOUGHT: Is a release in the 0.x.y phase usable code that just doesn't have API documentation yet? Is that what that means?
e.g. Tensorflow has releases on GitHub starting at 0.5.0. Is this acceptable per semantic versioning, or are they simply not following semver and using something else?
From the spec:
4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Why do some GitHub repos have 0.x.y releases if version 1.0.0 is the first public API release per SemVer2?
Because the maintainers do not wish to give the impression that their code/API's are stable or ready for production. They are reserving the right to remove or modify any of their API's without warning, for any reason they deem appropriate.
THOUGHT: Is a release in the 0.x.y phase usable code that just doesn't have API documentation yet? Is that what that means?
It means exactly what the spec says it means. If that's not clear enough, then you'd have to ask each of those repo's maintainers, what they think it means. In general, you should always treat prerelease versions as dangerous, unreliable, and subject to change without notice. Do not deploy any prerelease version into production, without thorough testing prior to deployment.
e.g. Tensorflow has releases on GitHub starting at 0.5.0. Is this acceptable per semantic versioning, or are they simply not following semver and using something else?
You should ask them if they are following SemVer. Any random version triple may have the appearance of a SemVer string, but that does not mean the publisher is adhering to SemVer. If they say they are SemVer and the first publicly available version is 0.5.0, that's perfectly acceptable. It is common practice to start at 0.1.0 for prerelease of the first feature(s), but there is no rule that requires it. There is also no requirement that older, possibly less stable versions, be left in public view. Nor is there a requirement for continuity of the version history. Any random version may be removed from public view for any reason the publisher deems sufficient cause to remove them.
When a publisher issues their first major version, they are saying "here's an API that we will not break". The SemVer spec allows them to fix bugs in their code and documentation with patch level version bumps, and add non-breaking features with minor level version bumps. The spec does not say how big those bumps should be.
On GitHub, sometimes I see projects with "1.x" and "2.x" branches, in addition to tags. Take the Grails SpringSec plugin for example. It has both a master and 1.x branch, as well as several tags.
This has me curious:
At what point would these "1.x" and "2.x" (etc.) "version branches" be created? At what point would they be merged back with master?
At what point would artifacts be built from these "version branches"? In other words, "1.x" could mean "1.0.0" or "1.5.29"...but the latest version might be "1.7.14". What's the relation between the "1.x" branch and the "1.7.14" version of the binary (JAR, ZIP, whatever)?
If you're already going to go with "version branches", then what purpose would a tag possibly serve?
Here's a brief explanation of how branches and tags work and how best to use them.
1. Branches
Branches provide a means to separate your code into different development streams. Initially you start with one main branch (be it master, trunk or other common names). As your project evolves, you start needing certain stability while developing.
A good way to guarantee this is to start using more than one branch for your work. Consider the following: you're working on a feature whose development effort would be high and/or long-term. You wouldn't want to have this in your main branch, if it's something that will change the behavior of your currently existing code, as while it's work-in-progress, you might break things for other people. So, this is when you normally create feature (or topic) branches. When your code becomes stable enough, you merge your feature branch with the respective master. This approach helps you work in isolation from the rest of the developers. They can check your work and comment on it, propose fixes and all at the same time while keeping your master stable.
2. Tags
Tags are something to be considered permanent. They are a marker of your code at a given point in time. When you release version 1.2.3, you need to be able to tell exactly what was in this release, if somebody reports a bug, so that you would be able to reproduce it easily and also check if it has been resolved during development at a later stage when you've released newer versions.
3. Working With Branches And Releasing From Them
Consider you have multiple clients. Assume ClientA has a contract with you that they will pay to use version 1.2.3, while ClientB is a new client interested in your ground-breaking work on some feature in version 2.x that ClientA isn't all hyped up about and therefore not so willing to upgrade to. Your contract states that each client gets service for a year after their payment for your licenses. Yes, generally companies should push for their clients to upgrade to newer versions of their product/service, but quite often the clients are large institutions in which the pace of work and decision-taking is much slower than desired.
So, in order to be able to support both clients, you need to make sure that you have a proper branching strategy and that you will be able to work in isolation. This normally means you have a main branch like master on which all your bleeding-edge development is done. When certain features are ready, if they are needed on the respective branches for those clients, they are merged to their branches. So, if you have feature-15 developed on master and it's something that is needed for ClientB, you only merge it to their branch. If ClientA has reported a critical issue which seems to be only relevant to their product version and not reproducible in later versions, you apply a fix just for them and rollout a release.
Quite often, your contracts are such that you don't give your clients certain functionality, unless they've paid for it. Your pricing model could be annual service which covers free upgrades for the whole year, covering minor and major version. You could also have some clients which you've signed a few years ago and who are very slow at upgrading and thus this need for keeping different version lines alive for a longer period.
3.1. Branching and Tagging In a Multi-branch Environment
Consider you have the following branches:
master : latest development (3.x)
1.x : for your clients who insist on using older versions of your code
2.x : for a bit more up-to-date clients.
Branch 1.x will be used for releasing 1.x-SNAPSHOT-s; 2.0 for 2.x-SNAPSHOT and the master -- for your yet unreleased work on 3.x. Normally, it's a good idea to have a branch per major version which you are actively supporting. For minors you would branch off that branch (for example, version 2.0.3 would be off branch 2.0.x). When your work on a given iteration of features is considered done and stable enough, you create a tag off that branch for the version under development and you bump the version of your current development to the next minor version. I'm talking abstractly, as you haven't mentioned what build tool you're using. With Maven, for example, the version currently under development would be a SNAPSHOT and if your currently released one was from branch 2.x and your development version was 2.3-SNAPSHOT, then your newly released version would be 2.3 and your next development version would be 2.4-SNAPSHOT.
I hope this all makes more sense now.
First of all the 1.x branch is technically just a branch name, like dev, aFeature or any other string.
This is a different model of version control. For example it makes sense, if you sell different licences for different versions.
In this model, you normally don't merge the branches back into the master. You start these branches if you start a new version. Then you maintain them parallel to the master branch.
You then build your releases (you called them artifacts) directly on those branches, by setting "Tags". After that you can go on developing on the same branch. For example:
We create a branch 2.x. After developing a while on that branch, we just create a Tag 2.1.0 and go on developing on that branch. After some bug fixes on the same branch a Tag 2.1.1 and so on. The same work is done for branch 3.x and 4.x.
So the purpose of the Tags is, to freeze a certain state of the code and provide it to the end users.
I'm using clearcase as version control and JIRA as bug-tracking tool. Currently ccase and JIRA is not integrated for issue tracking. I'd like to integrate JIRA with ccase but I am a bit skeptical about the plugin available which is not supported/developed by the JIRA vendor. I doubt it's stability and reliability. What's the best way to integrated JIRA with clearcase. How effectively I can track bugs? I am specifically asking this because in our development practice we won't created too many branches. Rather we backmerge and maintain the branches. It will be left only if we've too many modifications in the branch and become quite unmanageable.
I never managed to make the Jira-ClearCase plugin work well, mainly because the polling mechanism (which queries the new versions through the ClearCaseIndexService) was:
too slow to return result
didn't scale well with large Vobs.
I ended up using a custom field for referencing the extended path of the element(s) concerned by a Jira ticket.
I may be working with Siebel CRM soon, and I'm looking for advice on using modern development practices and enterprise best practices.
Specifically I'd like advice on the following areas:
How should we set up version control (specifically with Subversion)? What kind of structure should our repository have? How should we handle branches and tags?
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
How should we separate development roles from Siebel Administrator roles? What should our build/test/deploy cycle look like?
It's not likely that I'll be able to obtain any new expensive tools for this, but if there's a paid tool that provides really great ROI, feel free to mention it.
If you have other recommendations along these lines, but not specifically addressed by one of my questions, feel free to add that as well.
How should we set up version control (specifically with Subversion)?
use the guidance provided in the documentation for Siebel Tools. But please note that Siebel does not build from the files in SVN so it will only be useful as an archival tool; you cannot manage your code or build from SVN.
What kind of structure should our repository have? How should we handle branches and tags?
Siebel development code is not built or managed in SVN so this is a pretty useless thing to do. Just note the date that you built your SRF and exported your Repo and match with a tag or branch in SVN.
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
Use Siebel Tools to do this. It has a built in 'checking' tool for obvious errors (all devs should be using this before they check in) and a diff tool (you will need to check against an older version of the same object - which you could drag out of SVN if you want). I normally automate the checking tool once a day and review the output logs, and automate build from the Siebel server 5 times a day and look for errors during the compile. Diffs via SVN and a standard diff tool might be possible, but the Siebel objects are stored as XML-like files in SVN and so are hard to read sometimes.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
QTP is the standard way to go - check on the Oracle web site for other vendors that they may recommend. You could also try Sikuli.
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
Not really.
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
Checkout the appropriate section of Siebel Bookshelf for current naming guidelines and use these always.
How should we separate development roles from Siebel Administrator roles?
Not sure what you mean.
What should our build/test/deploy cycle look like?
Build a new SRF and export a new Repo from Dev once a night. Once all the dev work has been checked-in and unit tests are done take the next SRF and Repo and push into the test environment. At this point in normal software development you'd branch your SVN and continue to develop on the trunk but Siebel is different because you cannot build from SVN and you cannot easily restore a whole lot of files from SVN into your build environment, so you're best to make hot fixes for test either in dev (and pause mainline dev development until that is done) or in the test environment, and do ugly backports to the development environment (that's what most people do in fact). Build a new SRF and export a new Repo from Test once a night and once that's good, snap a copy for your Production release.
Try to stick to cycles of no more than 4 weeks (1 week for desing/prototyping. 1 week for dev, 1 week for test, 1 week for bug fixes and deployment) - any longer than that and the overhead of planning will become too great.
Hints for an easier life: Avoid eScript except in Business Services (otherwise it becomes unmanageable); use all the Siebel built-in tools instead of rolling-your own; try to avoid any roll-up functionality (it always seems like a good idea but it always destroys performance); keep the number of screens and views to an absolute minimum; do not build views when you should be building reports instead; always make sure that EIM tables match and schema extensions that you make - even if you don't use EIM right now; try to build Integration Objects to match your logical schema - they are always useful (for web services, XML publishing) and a hell of a job to build after the fact; prefer Workflow Policies over run-time Events; don't add new sort or search specifications without indexes - ever ever ever; don't make by-reference links to the LOV table; always patch; if the vendor doesn't say that you can do something, never do it.
We have set up a complete Continuous Integration toolchain for our Siebel systems consisting of Subversion, Hudson, Jira, Siebel ADM and some self-written stuff integrating everything.
This helepd a lot, although Siebel "source code" is not as suitable for standard CI approaches as, say, some Java-based project.
And, YES, it is possible to put your files - including SIF - into your Subversion repository and use this as source for your deployments.
I'm planning to blog about this in http://siebel-ci.blogspot.de/ - stay tuned.
SVN/CVS are not suitable for Siebel, a few reasons being
a) Siebel objects are db objects and SVN/CVS etc store sif equivalent of the changes.
These changes are impossible to query except for some basic queries.
b) The integration between Siebel tools and SVN is a loosely coupled integration.
The ideal integration should be with the Siebel repository and invidual tools.
Take a look at our tool Object Hive it addresses many of the short comings of a files based version control.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive has been from the ground up specifically for Siebel version control, some of its features are:
1) Object Based repository similar to Siebel repository that stores all version history.
This makes is very easy to query changes and conduct code reviews based on the changes
2) A browser based GUI that is similar to Siebel tools to query for version history (no combing sif files for changes).
3) Seamless integration - directly integrates with the Siebel repository.
No messy installation for invidual developer.
4) Powerful reporting (realtime and batch) to easily identify changes over any time period.
5) Oracle Exa-ready certified.
I'm wondering if there is any best practice for maintaining your source code under version control among different companies. In Open Source there is a maintainer, who receives patches, decides on them and applies them. But what about closed sourced projects where different companies get different workloads and just commit them to the trunk and branches? Is this maintainer concept applicable to a project on which multiple companies work on?
You can choose from a wide range of version control systems. (Not only subversion)
With the "versioning" concept you are safe that no one damages the project permanently.
So there is no need for a manual approval process, especially when there are contracts for example between the participating companies.
I'd also set up a commit mailinglist so you have some kind of peer review of changes. So no changes can be done without anyone noticing them.
If applicable set up some kind of continous integration environment to keep the quality up.
I don't understand the question about the branches. The decision whether to use them or not is IMHO not depending on the fact that the commiters are employed in the same company or not.
Its really up to you to decide which workflow works best for the companies involved. Subversion has the ability to add permissions to your trunk and branches allowing you to lock down certain parts of your repository to people who are "trusted" with merge access to trunk. You'll need good communication amongst the companies. Using the open source Trac provides a wiki, integrated RSS feeds of the commits to the project and code browser.
Usually, each site works on its dedicated branch and can import the other remote site branch, to decide what to integrate in its own work.
But if a site need to work directly on the other site branch, one possible practice is the concept of branch membership which allows only one site at a time to work on a given branch.
(not sure it is possible with SVN though)
That allows for two remote site (with a large time shift) to work on the same task in a tightly integrated manner.
My recommendation : subversion, with that configured you give away a url and then checkout, update, get things done and when you guess that the project is ready, snapshot and deliver.